Re: [O] bug in org-habits

Hi John and Achim, John Wiegley writes: >> Achim Gratz writes: > >> I don't think so. Search for end of entry can be complex in itself and you >> would never know if the properties you find by looking back aren't belonging >> to an entry one level

Re: [O] bug in org-habits

> Bastien Guerry writes: > I think Achim's points above are very valid, and the flexibility offered by > the option above should be very carefully examined. I spoke to Nicolas directly and he mentioned that a goal for syntax regularity is to make it possible to reliably read

Re: [O] bug in org-habits

On 04/11/15 02:01, John Wiegley wrote: Nicolas Goaziou writes: Also, supporting both locations means that users will pay the full price in entries without a property drawer, even if they chose the fast path, i.e., drawer at the beginning of the entry, in the first

Re: [O] bug in org-habits

On Tuesday, 3 Nov 2015 at 20:01, John Wiegley wrote: [...] > I'm having a hard time buying the performance argument, since I've been using > Org-mode for many years, and never has this been a problem. You're making me > pay a cost (enforced structure), for a value only one of us perceives.

Re: [O] bug in org-habits

> Puneeth Chaganti writes: >> Actually there has been introduced a constraint on the ordering planning >> lines and property drawers in 8.3. See http://orgmode.org/Changes.html.> >> This at least invalidates to use PROPERTIES before SCHEDULED afaics. > Yes, that is

Re: [O] bug in org-habits

On Tue, Nov 3, 2015 at 3:26 PM, Marco Wahl wrote: > > > Actually there has been introduced a constraint on the ordering planning > lines and property drawers in 8.3. See http://orgmode.org/Changes.html. > > This at least invalidates to use PROPERTIES before SCHEDULED

Re: [O] bug in org-habits

"Mark A. Hershberger" writes: > org-habit.el is sensitive to the ordering PROPERTIES and SCHEDULED > and expects them /in only/ the following order: > > * TODO habit name > SCHEDULED: <2015-11-03 Tue 07:00 .+1d> > :PROPERTIES: > :LAST_REPEAT: [2015-11-02 Mon 07:54] >

Re: [O] bug in org-habits

> Nicolas Goaziou writes: > This is not a bug. The order is HEADLINE (SCHEDULED PROPERTIES). Ah, I had misspoken. It's not SCHEDULE-before-PROPERTIES that has broken for me, it is the inability to have PROPERTIES at the very end of the entry. Why must the properties

Re: [O] bug in org-habits

Hello, John Wiegley writes: >> Nicolas Goaziou writes: > >> This is not a bug. The order is HEADLINE (SCHEDULED PROPERTIES). > > Ah, I had misspoken. It's not SCHEDULE-before-PROPERTIES that has broken for > me, it is the inability to have

Re: [O] bug in org-habits

John Wiegley writes: > Thanks for discussing this with me, Nicolas. I appreciate there may be > technical complexities involved. Could we special-case allow PROPERTIES to be > the *very last thing* in an entry? I don't need it to float anywhere else. I > just like it to be at the end. Well,

Re: [O] bug in org-habits

> Achim Gratz writes: > I don't think so. Search for end of entry can be complex in itself and you > would never know if the properties you find by looking back aren't belonging > to an entry one level down unless you scanned the whole span again. Also, > properties can be

Re: [O] bug in org-habits

> Jonathan Leech-Pepin writes: > Wouldn't last item in entry scale without issues? Find end of headline > (start of next or end of buffer) and search backwards. If first element from > end is a property drawer you have it, otherwise you still know there is >

Re: [O] bug in org-habits

> Nicolas Goaziou writes: > I'd rather not have syntax too much customizable, for portability, ease of > maintenance, too. There are already too many mistakes in that area. Thanks for discussing this with me, Nicolas. I appreciate there may be technical complexities

Re: [O] bug in org-habits

> Nicolas Goaziou writes: > It is for efficiency reasons. Properties are an important feature in Org, > letting them anywhere in a potentially long entry doesn't scale well. Since it scales for my use case, can I please have a customization variable to relax this

Re: [O] bug in org-habits

John Wiegley writes: > Since it scales for my use case, can I please have a customization variable to > relax this restriction? I'd rather not have syntax too much customizable, for portability, ease of maintenance, too. There are already too many mistakes in that area.

Re: [O] bug in org-habits

> Nicolas Goaziou writes: > As a matter of fact, going to the end of an entry is not negligible, because > of inlinetasks. Also, it is not really O(1) since it depends on the size of > the entry. To get an idea, on my computer, moving past a 500 lines entry > takes

Re: [O] bug in org-habits

John Wiegley writes: > Thanks for discussing this with me, Nicolas. I appreciate there may be > technical complexities involved. Could we special-case allow PROPERTIES to be > the *very last thing* in an entry? I don't need it to float anywhere else. I > just like it to be at

Re: [O] bug in org-habits

> Achim Gratz writes: > Well, that's precisely the thing that doesn't scale and that Nicolas wanted > to avoid. Putting the properties at the beginning of an entry makes the > search pretty much constant time and if you find something else at the start > of the entry then

Re: [O] bug in org-habits

On November 3, 2015 4:31:11 PM EST, Achim Gratz wrote: >John Wiegley writes: >> Thanks for discussing this with me, Nicolas. I appreciate there may >be >> technical complexities involved. Could we special-case allow >PROPERTIES to be >> the *very last thing* in an entry? I

Re: [O] bug in org-habits

John Wiegley writes: >> Jonathan Leech-Pepin writes: >> Wouldn't last item in entry scale without issues? Find end of headline >> (start of next or end of buffer) and search backwards. If first element from >> end is a property drawer you have it, otherwise you

Re: [O] bug in org-habits

On 03/11/15 14:46, Marco Wahl wrote: John Wiegley writes: Puneeth Chaganti writes: Actually there has been introduced a constraint on the ordering planning lines and property drawers in 8.3. See http://orgmode.org/Changes.html.> This at least

Re: [O] bug in org-habits

Hello, Stelian Iancu writes: > I have an org file with calendar appointments. I also have attachments > to the appointments. The attachment appears in a PROPERTIES drawer. > > Now if I have the timestamp (plain one) before the drawer, I cannot > open the attachment. Pressing

Re: [O] bug in org-habits

John Wiegley writes: >> Puneeth Chaganti writes: > >>> Actually there has been introduced a constraint on the ordering planning >>> lines and property drawers in 8.3. See http://orgmode.org/Changes.html.> >>> This at least invalidates to use

[O] bug in org-habits

org-habit.el is sensitive to the ordering PROPERTIES and SCHEDULED and expects them /in only/ the following order: * TODO habit name SCHEDULED: <2015-11-03 Tue 07:00 .+1d> :PROPERTIES: :LAST_REPEAT: [2015-11-02 Mon 07:54] :STYLE: habit :END: Any other ordering, or doubling of PROPERTIES