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 down unless you scanned the whole span agai
> 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 and manipulate O
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.
John
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 place. This kind of
defeats so
> 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 around 0.001s. I can imagin
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.
I think it
> 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 any size and you ha
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 still know there is
>> none.
>
>
> 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
> none.
That sounds even better tha
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 don't need it to float
> 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 you know there aren'
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, that's
> 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 involved. Could we specia
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.
Also, please note that p
> 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 restriction? I prefer PROPER
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 PROPERTIES at the very end of the entry.
>
> Why mu
> 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 drawer appear before the
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 C-c C-a o just inser
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 invalidates to use PROPERTIES before SCHEDULED
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 PROPERTIES before SCHEDULED afaics.
>
>> Yes, that
> 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 correct and you can use th
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 afaics.
Yes, that is correc
"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]
> :STYLE: habit
> :END:
>
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 (e
24 matches
Mail list logo