Re: commenting out a SCHEDULED line does not remove todo from agenda.

[Carsten Dominik <carsten.dominik@gmail.com>]

On 17.1.2013, at 06:02, Nick Dokos <nicholas.dokos@hp.com> wrote:

> Nick Dokos <nicholas.dokos@hp.com> wrote:
> 
>> Rainer Stengele <rainer.stengele@online.de> wrote:
>> 
>>> Hi!
>>> 
>>> Imagine you have a todo like this:
>>> 
>>> ***** TODO a task
>>>      SCHEDULED: <2013-01-16 Mi +2m>
>>> 
>>> Now suppose you want to put that todo on hold. In order to no more see
>>> the scheduled date in the agenda I comment out the "SCHEDULED" line.
>>> I do not want to delete it because I maybe need it later again:
>>> 
>>> 
>>> ***** TODO a task
>>>      # SCHEDULED: <2013-01-16 Mi +2m>
>>> 
>>> The todo still appears in the agenda.
>>> Is this not counterintuitive?
>>> 
>> 
>> Try putting the # in column 1 (untested).
>> 
> 
> I've now tested it and it is as I thought: the comment character has to
> be in column 1. The reason is org-agenda-skip:
> 
> ,----
> | (defun org-agenda-skip ()
> |   "Throw to `:skip' in places that should be skipped.
> | Also moves point to the end of the skipped region, so that search can
> | continue from there."
> |   (let ((p (point-at-bol)) to)
> |     (when (org-in-src-block-p t) (throw :skip t))
> |     (and org-agenda-skip-archived-trees (not org-agenda-archives-mode)
> | 	 (get-text-property p :org-archived)
> | 	 (org-end-of-subtree t)
> | 	 (throw :skip t))
> |     (and org-agenda-skip-comment-trees
> | 	 (get-text-property p :org-comment)
> | 	 (org-end-of-subtree t)
> | 	 (throw :skip t))
> |     (if (equal (char-after p) ?#) (throw :skip t))
> |     (when (setq to (or (org-agenda-skip-eval org-agenda-skip-function-global)
> | 		       (org-agenda-skip-eval org-agenda-skip-function)))
> |       (goto-char to)
> |       (throw :skip t))))
> `----
> 
> It sets p to the point at the beginning of the line and then
> checks if the character after it is '#'. Only then does it skip
> the entry.

And this is done for speed.  Maybe Moore's law has progressed enough to relax this assumption?

- Carsten


> 
> Nick
> 
> 
> 
>