Re: [O] SCHEDULED in a comment line is not ignored by sparse-tree

2014-12-23 Thread Nicolas Goaziou
Hello,

James Harkins jamshar...@qq.com writes:

 This appears to be buggy behavior, but I'm asking here first in case it might 
 already have been fixed.

 A couple of months ago, I was trying to create a repeating timestamp for two 
 different days of the week. First I tried a diary-sexp, but that wasn't 
 compatible with habits, so I gave that up. But I didn't want to throw away 
 the string completely, because it took some digging to figure it out. So I 
 put #  at the beginning of the SCHEDULED line and thought that would be the 
 end of it. (In the source block, # has two spaces before it. These come 
 from C-c ' editing. In my original file, the # for the comment is flush 
 left.)

 #+BEGIN_SRC org
   ,** TODO Update lesson grades 2 
 :Comp:
  SCHEDULED: 2014-12-06 Sat 23:59 .+1w
  :PROPERTIES:
  :STYLE:habit
  :LOGGING:  TODO MAYBE INPROG MTG | DONE(!) POSTPONED CANCELED
  :END:
   #   SCHEDULED: %%(memq (calendar-day-of-week date) '(3 6))
 #+END_SRC

 Just now, I tried to open a sparse-tree view with a scheduled date range -- 
 C-c / c c D (set range) -- and got the message:

 byte-code: Bad timestamp `%%(memq (calendar-day-of-week date) '(3 6))'
 Error was: (Not a standard Org-mode time string: %%(memq
 (calendar-day-of-week date) '(3 6)))

This should be fixed. Thank you for reporting it.


Regards,

-- 
Nicolas Goaziou



Re: [O] SCHEDULED in a comment line is not ignored by sparse-tree

2014-12-03 Thread Sebastien Vauban
James Harkins wrote:
 This appears to be buggy behavior, but I'm asking here first in case
 it might already have been fixed. [...]

 #+BEGIN_SRC org
   ,** TODO Update lesson grades 2 
 :Comp:
  SCHEDULED: 2014-12-06 Sat 23:59 .+1w
  :PROPERTIES:
  :STYLE:habit
  :LOGGING:  TODO MAYBE INPROG MTG | DONE(!) POSTPONED CANCELED
  :END:
   #   SCHEDULED: %%(memq (calendar-day-of-week date) '(3 6))
 #+END_SRC

 byte-code: Bad timestamp `%%(memq (calendar-day-of-week date) '(3 6))'
 Error was: (Not a standard Org-mode time string: %%(memq 
 (calendar-day-of-week date) '(3 6)))

 This is the only occurrence of memq anywhere in this org file, so it
 *must* be coming from this line. So, whatever regexp is handling
 scheduled timestamp searches doesn't check whether the line is
 a comment or not.

I had reported that very same issue in May 2014:

  http://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg00756.html

Still there...

Best regards,
  Seb

-- 
Sebastien Vauban




[O] SCHEDULED in a comment line is not ignored by sparse-tree

2014-12-02 Thread James Harkins
This appears to be buggy behavior, but I'm asking here first in case it might 
already have been fixed.

A couple of months ago, I was trying to create a repeating timestamp for two 
different days of the week. First I tried a diary-sexp, but that wasn't 
compatible with habits, so I gave that up. But I didn't want to throw away the 
string completely, because it took some digging to figure it out. So I put #  
at the beginning of the SCHEDULED line and thought that would be the end of it. 
(In the source block, # has two spaces before it. These come from C-c ' 
editing. In my original file, the # for the comment is flush left.)

#+BEGIN_SRC org
  ,** TODO Update lesson grades 2 :Comp:
 SCHEDULED: 2014-12-06 Sat 23:59 .+1w
 :PROPERTIES:
 :STYLE:habit
 :LOGGING:  TODO MAYBE INPROG MTG | DONE(!) POSTPONED CANCELED
 :END:
  #   SCHEDULED: %%(memq (calendar-day-of-week date) '(3 6))
#+END_SRC

Just now, I tried to open a sparse-tree view with a scheduled date range -- C-c 
/ c c D (set range) -- and got the message:

byte-code: Bad timestamp `%%(memq (calendar-day-of-week date) '(3 6))'
Error was: (Not a standard Org-mode time string: %%(memq (calendar-day-of-week 
date) '(3 6)))

This is the only occurrence of memq anywhere in this org file, so it *must* be 
coming from this line. So, whatever regexp is handling scheduled timestamp 
searches doesn't check whether the line is a comment or not.

There may be a valid reason for this behavior, but I tend to think a comment 
should always be a comment.

hjh