[RFC] Change property drawer syntax

[RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

As discussed previously, I would like to modify property drawers syntax.
The change is simple: they must be located right after a headline and
its planning line, if any.  Therefore the following cases are valid

  * Headline
    :PROPERTIES:
    :KEY: value
    :END:

  * Headline
    SCHEDULED: <2014-10-14 mar.>
    :PROPERTIES:
    :KEY: value
    :END:

but, in the following case, the scheduled keyword will not be recognized

  * Headline
    :PROPERTIES:
    :KEY: value
    :END:
    SCHEDULED: <2014-10-14 mar.>

When not empty, they also have to contain only node properties.
Moreover, node properties' keys can only contain non-whitespace
characters and cannot end with a plus sign (which is used for
accumulation). Value can contain anything but a newline character.

Thus, the following property drawer is invalid

  * Headline
    :PROPERTIES:
    :KEY: value
    Some text.
    :END:

Any invalid property drawer becomes de facto a regular drawer, with
"PROPERTIES" as its name.

Besides defining exactly the syntax of property drawers, it should also
make the property API faster in some cases. Indeed, there's no need to
search through entire (possibly huge) sections in order to find
properties attached to a headline.

However, it will break some Org documents. In particular, TODO-states
changes are usually logged before any drawer, including properties
drawers. The following function repairs them.

  (defun org-repair-property-drawers ()
    "Fix properties drawers in current buffer.
  Ignore non Org buffers."
    (when (eq major-mode 'org-mode)
      (org-with-wide-buffer
       (goto-char (point-min))
       (let ((case-fold-search t)
             (inline-re (and (featurep 'org-inlinetask)
                             (concat (org-inlinetask-outline-regexp)
                                     "END[ \t]*$"))))
         (org-map-entries
          (lambda ()
            (unless (and inline-re (org-looking-at-p inline-re))
              (save-excursion
                (let ((end (save-excursion (outline-next-heading) (point))))
                  (forward-line)
                  (when (org-looking-at-p org-planning-line-re) (forward-line))
                  (when (and (< (point) end)
                             (not (org-looking-at-p org-property-drawer-re))
                             (save-excursion
                               (re-search-forward org-property-drawer-re end t)))
                    (insert (delete-and-extract-region
                             (match-beginning 0)
                             (min (1+ (match-end 0)) end)))
                    (unless (bolp) (insert "\n"))))))))))))

Internally, changes are somewhat invasive, as they include a rewrite of
almost all the property API. They also alter clocking, tags, todo
keywords, logging, initialization, hopefully in an invisible manner.

I pushed a new branch, "top-properties" in the repository for code
review and testing. It includes unit tests, documentation and an
ORG-NEWS entry.

Feedback welcome.


Regards,

-- 
Nicolas Goaziou                                                0x80A93738

Re: [RFC] Change property drawer syntax

[Andreas Leha]

Hi Nicolas,

My only 'concern' is that it looks awkward or at least unfamiliar when the
property drawer is closed (which it is always in my documents).

I guess than it would change from

    *** Call XXX
        :PROPERTIES:...
    <2014-10-16 Thu 13:00-14:00>

to

    *** Call XXX
    <2014-10-16 Thu 13:00-14:00>
        :PROPERTIES:...

which has a folded item 'in the middle of text' rather than right below the
heading.

I'll get used to that, I guess.

Regards,
Andreas





Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> As discussed previously, I would like to modify property drawers syntax.
> The change is simple: they must be located right after a headline and
> its planning line, if any.  Therefore the following cases are valid
>
>   * Headline
>     :PROPERTIES:
>     :KEY: value
>     :END:
>
>   * Headline
>     SCHEDULED: <2014-10-14 mar.>
>     :PROPERTIES:
>     :KEY: value
>     :END:
>
> but, in the following case, the scheduled keyword will not be recognized
>
>   * Headline
>     :PROPERTIES:
>     :KEY: value
>     :END:
>     SCHEDULED: <2014-10-14 mar.>
>
> When not empty, they also have to contain only node properties.
> Moreover, node properties' keys can only contain non-whitespace
> characters and cannot end with a plus sign (which is used for
> accumulation). Value can contain anything but a newline character.
>
> Thus, the following property drawer is invalid
>
>   * Headline
>     :PROPERTIES:
>     :KEY: value
>     Some text.
>     :END:
>
> Any invalid property drawer becomes de facto a regular drawer, with
> "PROPERTIES" as its name.
>
> Besides defining exactly the syntax of property drawers, it should also
> make the property API faster in some cases. Indeed, there's no need to
> search through entire (possibly huge) sections in order to find
> properties attached to a headline.
>
> However, it will break some Org documents. In particular, TODO-states
> changes are usually logged before any drawer, including properties
> drawers. The following function repairs them.
>
>   (defun org-repair-property-drawers ()
>     "Fix properties drawers in current buffer.
>   Ignore non Org buffers."
>     (when (eq major-mode 'org-mode)
>       (org-with-wide-buffer
>        (goto-char (point-min))
>        (let ((case-fold-search t)
>              (inline-re (and (featurep 'org-inlinetask)
>                              (concat (org-inlinetask-outline-regexp)
>                                      "END[ \t]*$"))))
>          (org-map-entries
>           (lambda ()
>             (unless (and inline-re (org-looking-at-p inline-re))
>               (save-excursion
>                 (let ((end (save-excursion (outline-next-heading) (point))))
>                   (forward-line)
>                   (when (org-looking-at-p org-planning-line-re) (forward-line))
>                   (when (and (< (point) end)
>                              (not (org-looking-at-p org-property-drawer-re))
>                              (save-excursion
>                                (re-search-forward org-property-drawer-re end t)))
>                     (insert (delete-and-extract-region
>                              (match-beginning 0)
>                              (min (1+ (match-end 0)) end)))
>                     (unless (bolp) (insert "\n"))))))))))))
>
> Internally, changes are somewhat invasive, as they include a rewrite of
> almost all the property API. They also alter clocking, tags, todo
> keywords, logging, initialization, hopefully in an invisible manner.
>
> I pushed a new branch, "top-properties" in the repository for code
> review and testing. It includes unit tests, documentation and an
> ORG-NEWS entry.
>
> Feedback welcome.
>
>
> Regards,

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> My only 'concern' is that it looks awkward or at least unfamiliar when the
> property drawer is closed (which it is always in my documents).
>
> I guess than it would change from
>
>     *** Call XXX
>         :PROPERTIES:...
>     <2014-10-16 Thu 13:00-14:00>
>
> to
>
>     *** Call XXX
>     <2014-10-16 Thu 13:00-14:00>
>         :PROPERTIES:...

No it wouldn't. PROPERTIES must be right after the deadline. <2014-10-16
Thu 13:00-14:00> is a mere timestamp, not a planning info line (with
SCHEDULED, DEADLINE, CLOSED keywords).

The second case is not a property drawer.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Eric Abrahamsen]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> As discussed previously, I would like to modify property drawers syntax.
> The change is simple: they must be located right after a headline and
> its planning line, if any.  Therefore the following cases are valid
>
>   * Headline
>     :PROPERTIES:
>     :KEY: value
>     :END:
>
>   * Headline
>     SCHEDULED: <2014-10-14 mar.>
>     :PROPERTIES:
>     :KEY: value
>     :END:
>
> but, in the following case, the scheduled keyword will not be recognized
>
>   * Headline
>     :PROPERTIES:
>     :KEY: value
>     :END:
>     SCHEDULED: <2014-10-14 mar.>
>
> When not empty, they also have to contain only node properties.
> Moreover, node properties' keys can only contain non-whitespace
> characters and cannot end with a plus sign (which is used for
> accumulation). Value can contain anything but a newline character.
>
> Thus, the following property drawer is invalid
>
>   * Headline
>     :PROPERTIES:
>     :KEY: value
>     Some text.
>     :END:
>
> Any invalid property drawer becomes de facto a regular drawer, with
> "PROPERTIES" as its name.
>
> Besides defining exactly the syntax of property drawers, it should also
> make the property API faster in some cases. Indeed, there's no need to
> search through entire (possibly huge) sections in order to find
> properties attached to a headline.
>
> However, it will break some Org documents. In particular, TODO-states
> changes are usually logged before any drawer, including properties
> drawers. The following function repairs them.
>
>   (defun org-repair-property-drawers ()
>     "Fix properties drawers in current buffer.
>   Ignore non Org buffers."
>     (when (eq major-mode 'org-mode)
>       (org-with-wide-buffer
>        (goto-char (point-min))
>        (let ((case-fold-search t)
>              (inline-re (and (featurep 'org-inlinetask)
>                              (concat (org-inlinetask-outline-regexp)
>                                      "END[ \t]*$"))))
>          (org-map-entries
>           (lambda ()
>             (unless (and inline-re (org-looking-at-p inline-re))
>               (save-excursion
>                 (let ((end (save-excursion (outline-next-heading) (point))))
>                   (forward-line)
>                   (when (org-looking-at-p org-planning-line-re) (forward-line))
>                   (when (and (< (point) end)
>                              (not (org-looking-at-p org-property-drawer-re))
>                              (save-excursion
>                                (re-search-forward org-property-drawer-re end t)))
>                     (insert (delete-and-extract-region
>                              (match-beginning 0)
>                              (min (1+ (match-end 0)) end)))
>                     (unless (bolp) (insert "\n"))))))))))))
>
> Internally, changes are somewhat invasive, as they include a rewrite of
> almost all the property API. They also alter clocking, tags, todo
> keywords, logging, initialization, hopefully in an invisible manner.
>
> I pushed a new branch, "top-properties" in the repository for code
> review and testing. It includes unit tests, documentation and an
> ORG-NEWS entry.

Sounds like fun! Here's maybe a bug. In this test case:

* Here's something
** Second level
   :PROPERTIES:
   :ID:       06b778b5-72a5-45b5-aea6-2d0fef0fd24b
   :END:

Calling org-entry-put on the first heading will actually place the
property on its child. Reason being that, when org-entry-put calls
org-get-property-block, and that calls org-insert-property-drawer, point
has already been advanced to the beginning of the "** Second level"
line. 

org-insert-property-drawer examines the child instead of the parent,
thinks it doesn't have to insert anything, and returns nil. Code later
in org-get-property-block locates the ":END:" belonging to the child,
assumes that's the end of the parent's block, and sticks the new
property there. (I found this because org-id-get-create placed new ID
values in the child's property drawer.)

That was a mouthful, but I'm not going to venture a patch at this point!

Eric

Re: [RFC] Change property drawer syntax

[Michael Brand]

Hi Nicolas

On Tue, Oct 14, 2014 at 4:42 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> As discussed previously, I would like to modify property drawers syntax.
> The change is simple: they must be located right after a headline and
> its planning line, if any.  Therefore the following cases are valid
>
>   * Headline
>     :PROPERTIES:
>     :KEY: value
>     :END:
>
>   * Headline
>     SCHEDULED: <2014-10-14 mar.>
>     :PROPERTIES:
>     :KEY: value
>     :END:

What about legacy multi line plain timestamp and planning info:

    * Yearly meeting
      <2013-09-22 Sun>
      <2014-10-19 Sun>
      SCHEDULED: <2015-01-01 Thu> Add next plain timestamp.
      :PROPERTIES:
      :KEY:      value
      :END:

    * Yearly task
      DEADLINE: <2013-09-22 Sun -2d>
      DEADLINE: <2014-10-19 Sun -2d>
      SCHEDULED: <2015-01-01 Thu> Add next deadline.
      :PROPERTIES:
      :KEY:      value
      :END:

Will they also become invalid as I tend to understand?

Can they be reordered as

    * Yearly meeting
      SCHEDULED: <2015-01-01 Thu> Add next plain timestamp.
      :PROPERTIES:
      :KEY:      value
      :END:
      <2014-10-19 Sun>
      <2013-09-22 Sun>

    * Yearly task
      [It seems it can not be only reordered.]

or will they have to be transformed into sub-headings like

    * Yearly meeting
      :PROPERTIES:
      :KEY:      value
      :END:
    ** Yearly meeting - 2013
       <2013-09-22 Sun>
    ** Yearly meeting - 2014
       <2014-10-19 Sun>
    ** Yearly meeting - Add next plain timestamp
       SCHEDULED: <2015-01-01 Thu>

    * Yearly task
      :PROPERTIES:
      :KEY:      value
      :END:
    ** Yearly task - 2013
       DEADLINE: <2013-09-22 Sun -2d>
    ** Yearly task - 2014
       DEADLINE: <2014-10-19 Sun -2d>
    ** Yearly task - Add next deadline
       SCHEDULED: <2015-01-01 Thu>

?

Michael

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Sounds like fun! Here's maybe a bug. In this test case:
>
> * Here's something
> ** Second level
>    :PROPERTIES:
>    :ID:       06b778b5-72a5-45b5-aea6-2d0fef0fd24b
>    :END:

Good catch. Fixed, thank you.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Michael Brand <michael.ch.brand@gmail.com> writes:

> What about legacy multi line plain timestamp and planning info:
>
>     * Yearly meeting
>       <2013-09-22 Sun>
>       <2014-10-19 Sun>
>       SCHEDULED: <2015-01-01 Thu> Add next plain timestamp.
>       :PROPERTIES:
>       :KEY:      value
>       :END:

This is invalid, and has been so for a long time. Quoting first footnote
in (info "(org) Inserting deadline/schedule"):

  The ‘SCHEDULED’ and ‘DEADLINE’ dates are inserted on the line right
  below the headline. Don’t put any text between this line and the
  headline.

This footnote was inserted in c431fef47a7cbcc6ea79e3a945bc22cca4b4be96,
which is dating back from march 2011.

>     * Yearly task
>       DEADLINE: <2013-09-22 Sun -2d>
>       DEADLINE: <2014-10-19 Sun -2d>
>       SCHEDULED: <2015-01-01 Thu> Add next deadline.
>       :PROPERTIES:
>       :KEY:      value
>       :END:

This is also invalid, per the footnote above. Also, you cannot have some
text on the planning line.

> Will they also become invalid as I tend to understand?

They are already. My proposal doesn't change anything about it.

> Can they be reordered as
>
>     * Yearly meeting
>       SCHEDULED: <2015-01-01 Thu> Add next plain timestamp.
>       :PROPERTIES:
>       :KEY:      value
>       :END:
>       <2014-10-19 Sun>
>       <2013-09-22 Sun>

If you remove "Add next plain timestamp.", this is perfectly valid.

  * Yearly meeting
    SCHEDULED: <2015-01-01 Thu>
    :PROPERTIES:
    :KEY:      value
    :END:
    <2014-10-19 Sun>
    <2013-09-22 Sun>

> or will they have to be transformed into sub-headings like
>
>     * Yearly meeting
>       :PROPERTIES:
>       :KEY:      value
>       :END:
>     ** Yearly meeting - 2013
>        <2013-09-22 Sun>
>     ** Yearly meeting - 2014
>        <2014-10-19 Sun>
>     ** Yearly meeting - Add next plain timestamp
>        SCHEDULED: <2015-01-01 Thu>
>
>     * Yearly task
>       :PROPERTIES:
>       :KEY:      value
>       :END:
>     ** Yearly task - 2013
>        DEADLINE: <2013-09-22 Sun -2d>
>     ** Yearly task - 2014
>        DEADLINE: <2014-10-19 Sun -2d>
>     ** Yearly task - Add next deadline
>        SCHEDULED: <2015-01-01 Thu>

I don't understand this.

Again, there is one possible planning info line per entry. If there is
one, the property drawer has to be inserted right below it.  Otherwise,
it needs to be right after the headline itself.

This has nothing to do with plain timestamps, i.e., <2014-10-19 Sun> and
<2013-09-22 Sun> in your example.

I hope this is clearer now.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Eric Abrahamsen]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> As discussed previously, I would like to modify property drawers syntax.
> The change is simple: they must be located right after a headline and
> its planning line, if any.  Therefore the following cases are valid

Is there any chance this has messed up file-local #+TODO: keyword
definitions? Specifically, it looks like, if there are more than one of
those options lines, they aren't parsed or applied in this test branch.

This works in both master and top-properties:

#+TODO: FIX | BREAK

* FIX My car


This works in master but *not* top-properties:

#+TODO: FIX | BREAK
#+TODO: EMAIL | REPLY

* FIX My car
* EMAIL My dad


In the second case, none of the TODO keywords are recognized as valid
keywords. The lines don't appear to be parsed at all -- usually lines
like that override the globally-defined keyword list, but in this case
the global definitions are in effect.

The docs still say multiple lines are permitted...

Thanks,
Eric

Re: [RFC] Change property drawer syntax

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 4942 bytes --]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,

Hi

I am not using org that much for schedulig, todo items, and other
similar topics, but mainly for literate programming, so I will comment
From that perspective.

>
> As discussed previously, I would like to modify property drawers syntax.
> The change is simple: they must be located right after a headline and
> its planning line, if any.  Therefore the following cases are valid
>
>   * Headline
>     :PROPERTIES:
>     :KEY: value
>     :END:
>
>   * Headline
>     SCHEDULED: <2014-10-14 mar.>
>     :PROPERTIES:
>     :KEY: value
>     :END:
>
> but, in the following case, the scheduled keyword will not be recognized
>
>   * Headline
>     :PROPERTIES:
>     :KEY: value
>     :END:
>     SCHEDULED: <2014-10-14 mar.>
>
> When not empty, they also have to contain only node properties.

No problems so far from my side.

> Moreover, node properties' keys can only contain non-whitespace
> characters and cannot end with a plus sign (which is used for
> accumulation). 

This is problematic for me, as I am using it extensively in the case
of :header-args.

I set file wide header-arg and add the ones which have to change per
subtree / node:

--8<---------------cut here---------------start------------->8---
#+Property: header-args :tangle-mode (identity #o444)
#+PROPERTY: header-args+ :tangle no
#+PROPERTY: header-args+ :mkdirp yes
#+PROPERTY: header-args+ :exports both
#+PROPERTY: header-args+ :comments both
#+PROPERTY: header-args+ :padline no
#+PROPERTY: header-args+ :eval no-export

* To be tangled but *never* executed
:PROPERTIES:
:header-args+: :eval never
:END:
** some code
:PROPERTIES:
:comments: no
:header-args+: :tangle ./code.R
:header-args+: :padline no
:header-args+: :no-expand TRUE
:header-args+: :comments no
:END:
#+begin_src R 
## some code
#+end_src

* Not to be tangled but can be executed
#+begin_src R 
## some other code
#+end_src
--8<---------------cut here---------------end--------------->8---

So if I understand you correctly, this would break this approach, which
I think is very valuable in literate programming and reproducible research.

> Value can contain anything but a newline character.
>
> Thus, the following property drawer is invalid
>
>   * Headline
>     :PROPERTIES:
>     :KEY: value
>     Some text.
>     :END:
>
> Any invalid property drawer becomes de facto a regular drawer, with
> "PROPERTIES" as its name.
>
> Besides defining exactly the syntax of property drawers, it should also
> make the property API faster in some cases. Indeed, there's no need to
> search through entire (possibly huge) sections in order to find
> properties attached to a headline.
>
> However, it will break some Org documents. In particular, TODO-states
> changes are usually logged before any drawer, including properties
> drawers. The following function repairs them.

At the moment, I do not see any way on how I can replace the + in the
properties drawer - or am I missing something very basic here?

Cheers,

Rainer

>
>   (defun org-repair-property-drawers ()
>     "Fix properties drawers in current buffer.
>   Ignore non Org buffers."
>     (when (eq major-mode 'org-mode)
>       (org-with-wide-buffer
>        (goto-char (point-min))
>        (let ((case-fold-search t)
>              (inline-re (and (featurep 'org-inlinetask)
>                              (concat (org-inlinetask-outline-regexp)
>                                      "END[ \t]*$"))))
>          (org-map-entries
>           (lambda ()
>             (unless (and inline-re (org-looking-at-p inline-re))
>               (save-excursion
>                 (let ((end (save-excursion (outline-next-heading) (point))))
>                   (forward-line)
>                   (when (org-looking-at-p org-planning-line-re) (forward-line))
>                   (when (and (< (point) end)
>                              (not (org-looking-at-p org-property-drawer-re))
>                              (save-excursion
>                                (re-search-forward org-property-drawer-re end t)))
>                     (insert (delete-and-extract-region
>                              (match-beginning 0)
>                              (min (1+ (match-end 0)) end)))
>                     (unless (bolp) (insert "\n"))))))))))))
>
> Internally, changes are somewhat invasive, as they include a rewrite of
> almost all the property API. They also alter clocking, tags, todo
> keywords, logging, initialization, hopefully in an invisible manner.
>
> I pushed a new branch, "top-properties" in the repository for code
> review and testing. It includes unit tests, documentation and an
> ORG-NEWS entry.
>
> Feedback welcome.
>
>
> Regards,

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Is there any chance this has messed up file-local #+TODO: keyword
> definitions?

The changes mess with todo keywords, tags, properties, initialization
(local keywords), clock and logging. However, the modifications are
internal and no change in behaviour is expected.

> Specifically, it looks like, if there are more than one of those
> options lines, they aren't parsed or applied in this test branch.
>
> This works in both master and top-properties:
>
> #+TODO: FIX | BREAK
>
> * FIX My car
>
>
> This works in master but *not* top-properties:
>
> #+TODO: FIX | BREAK
> #+TODO: EMAIL | REPLY
>
> * FIX My car
> * EMAIL My dad

Fixed. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Rainer M Krug <Rainer@krugs.de> writes:


>> Moreover, node properties' keys can only contain non-whitespace
>> characters and cannot end with a plus sign (which is used for
>> accumulation). 
>
> This is problematic for me, as I am using it extensively in the case
> of :header-args.
>
> I set file wide header-arg and add the ones which have to change per
> subtree / node:
>
> #+Property: header-args :tangle-mode (identity #o444)
> #+PROPERTY: header-args+ :tangle no
> #+PROPERTY: header-args+ :mkdirp yes
> #+PROPERTY: header-args+ :exports both
> #+PROPERTY: header-args+ :comments both
> #+PROPERTY: header-args+ :padline no
> #+PROPERTY: header-args+ :eval no-export

I wasn't clear. A property key cannot end with a plus sign, because the
plus sign has another meaning. IOW, "header-args+" is perfectly valid,
but the true property key is "header-args", "+" meaning that values
should be accumulated.

This behaviour is unchanged.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Eric Abrahamsen]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Is there any chance this has messed up file-local #+TODO: keyword
>> definitions?
>
> The changes mess with todo keywords, tags, properties, initialization
> (local keywords), clock and logging. However, the modifications are
> internal and no change in behaviour is expected.
>
>> Specifically, it looks like, if there are more than one of those
>> options lines, they aren't parsed or applied in this test branch.
>>
>> This works in both master and top-properties:
>>
>> #+TODO: FIX | BREAK
>>
>> * FIX My car
>>
>>
>> This works in master but *not* top-properties:
>>
>> #+TODO: FIX | BREAK
>> #+TODO: EMAIL | REPLY
>>
>> * FIX My car
>> * EMAIL My dad
>
> Fixed. Thank you.

Looks good! Thanks very much.

Re: [RFC] Change property drawer syntax

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Rainer M Krug <Rainer@krugs.de> writes:
>
>
>>> Moreover, node properties' keys can only contain non-whitespace
>>> characters and cannot end with a plus sign (which is used for
>>> accumulation). 
>>
>> This is problematic for me, as I am using it extensively in the case
>> of :header-args.
>>
>> I set file wide header-arg and add the ones which have to change per
>> subtree / node:
>>
>> #+Property: header-args :tangle-mode (identity #o444)
>> #+PROPERTY: header-args+ :tangle no
>> #+PROPERTY: header-args+ :mkdirp yes
>> #+PROPERTY: header-args+ :exports both
>> #+PROPERTY: header-args+ :comments both
>> #+PROPERTY: header-args+ :padline no
>> #+PROPERTY: header-args+ :eval no-export
>
> I wasn't clear. A property key cannot end with a plus sign, because the
> plus sign has another meaning. IOW, "header-args+" is perfectly valid,
> but the true property key is "header-args", "+" meaning that values
> should be accumulated.

OK - thanks for the clarification.

Then I am happy with the proposal.

Rainer

>
> This behaviour is unchanged.
>
>
> Regards,

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: [RFC] Change property drawer syntax

[Michael Brand]

Hi Nicolas

My questions were misleading, I'm sorry. I should not have asked about
"valid" and not have added a property drawer. Rather I wanted to know
when regarding only the agenda whether I can still postpone to make
these examples valid:

    * Yearly meeting
      <2013-08-11 Sun>
      <2014-12-21 Sun>
      SCHEDULED: <2015-02-05 Thu>
      <2015-09-20 Sun>
      - SCHEDULED is used to remind to add a plain timestamp for the
        meeting date in 2016 that will be published latest by
        2015-02-05. SCHEDULED will be shifted for the next year after
        that.
    * Headline

Will the invalid example above continue on the new branch
top-properties to show also the SCHEDULED in the default agenda view?

    * Yearly task
      DEADLINE: [2013-08-11 Sun -2d]
      DEADLINE: <2014-12-21 Sun -2d>
      SCHEDULED: <2015-02-05 Thu>
      DEADLINE: <2015-09-20 Sun -2d>
      - SCHEDULED is used to remind to add a DEADLINE for the due date
        in 2016 that will be published latest by 2015-02-05. SCHEDULED
        will be shifted for the next year after that.
      - All past DEADLINE are inactive and document when the task had
        to be done in the past.
    * Headline

Will the invalid example above continue on the new branch
top-properties to show all three active timestamps in the default
agenda view?

Michael

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Michael Brand <michael.ch.brand@gmail.com> writes:

> My questions were misleading, I'm sorry. I should not have asked about
> "valid" and not have added a property drawer.

Actually valid/invalid is a bit strong. There is no such thing as
a syntax error in Org. However, Org may differ from your expectations in
some cases.

Instead of using "invalid", I'll describe what Org is supposed to see
and what you can expect.

> Rather I wanted to know when regarding only the agenda whether I can
> still postpone to make these examples valid:
>
>     * Yearly meeting
>       <2013-08-11 Sun>
>       <2014-12-21 Sun>
>       SCHEDULED: <2015-02-05 Thu>
>       <2015-09-20 Sun>
>       - SCHEDULED is used to remind to add a plain timestamp for the
>         meeting date in 2016 that will be published latest by
>         2015-02-05. SCHEDULED will be shifted for the next year after
>         that.
>     * Headline
>
> Will the invalid example above continue on the new branch
> top-properties to show also the SCHEDULED in the default agenda view?

Here, SCHEDULED keyword is not located right after the headline and,
therefore, loses its meaning. Org really sees

  * Yearly meeting
    <2013-08-11 Sun>
    <2014-12-21 Sun>
    xxxxxxxxxx <2015-02-05 Thu>
    <2015-09-20 Sun>
    xxx
    * Headline

In this case, 4 plain time-stamps should appear in the agenda. None of
them should be "scheduled". (org-entry-get (point) "SCHEDULED") will
return nil.

>     * Yearly task
>       DEADLINE: [2013-08-11 Sun -2d]
>       DEADLINE: <2014-12-21 Sun -2d>
>       SCHEDULED: <2015-02-05 Thu>
>       DEADLINE: <2015-09-20 Sun -2d>
>       - SCHEDULED is used to remind to add a DEADLINE for the due date
>         in 2016 that will be published latest by 2015-02-05. SCHEDULED
>         will be shifted for the next year after that.
>       - All past DEADLINE are inactive and document when the task had
>         to be done in the past.
>     * Headline
>
> Will the invalid example above continue on the new branch
> top-properties to show all three active timestamps in the default
> agenda view?

Here, DEADLINE is correctly located, but isn't followed by an active
time-stamp. It also loses its meaning, leading to:

  * Yearly task
    xxxxxxxxxx [2013-08-11 Sun -2d]
    xxxxxxxxxx <2014-12-21 Sun -2d>
    xxxxxxxxxx <2015-02-05 Thu>
    xxxxxxxxxx <2015-09-20 Sun -2d>
    xxx
    * Headline

The three active timestamps should appear in the agenda. None of them
should be either "scheduled" or "deadline". Both (org-entry-get (point)
"SCHEDULED") and (org-entry-get (point) "DEADLINE") will return nil.

If anything different happens, it is a bug. I don't know if that bug
still exists in "top-properties" branch. Anyway, I suggest to not count
on it, as it may be fixed, sooner or later.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> As discussed previously, I would like to modify property drawers syntax.

I think the syntax change looks great (based on the proposal)!

Thanks a bunch!

—Rasmus

-- 
Dobbelt-A

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> As discussed previously, I would like to modify property drawers syntax.
> The change is simple: they must be located right after a headline and
> its planning line, if any.

[...]

> I pushed a new branch, "top-properties" in the repository for code
> review and testing. It includes unit tests, documentation and an
> ORG-NEWS entry.
>
> Feedback welcome.

If there is no more feedback or objection, I will merge the branch on
Tuesday.

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>> As discussed previously, I would like to modify property drawers syntax.
>> The change is simple: they must be located right after a headline and
>> its planning line, if any.
>
> [...]
>
>> I pushed a new branch, "top-properties" in the repository for code
>> review and testing. It includes unit tests, documentation and an
>> ORG-NEWS entry.

> If there is no more feedback or objection, I will merge the branch on
> Tuesday.

Done.

Re: [RFC] Change property drawer syntax

[Christian Egli]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> As discussed previously, I would like to modify property drawers syntax.
>> The change is simple: they must be located right after a headline and
>> its planning line, if any.

>> Feedback welcome.
>
> If there is no more feedback or objection, I will merge the branch on
> Tuesday.

I see that it is too late now, but let me still note that the
taskjuggler exporter is quite liberal in what attribute values it allows
for exporting. I've never used it and I haven't ever seen anyone using
it, but in theory you could give a task a note or a journalentry which
spans multiple lines. This will no longer be possible with this change.

I guess if anyone ever wants to specify notes and journalentries for a
task and export this to taskjuggler they will have to put it on one
line.

Thanks
Christian
-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: [RFC] Change property drawer syntax

[John Hendy]

On Fri, Oct 31, 2014 at 8:10 AM, Christian Egli <christian.egli@sbs.ch> wrote:
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>
>>> As discussed previously, I would like to modify property drawers syntax.
>>> The change is simple: they must be located right after a headline and
>>> its planning line, if any.
>
>>> Feedback welcome.
>>
>> If there is no more feedback or objection, I will merge the branch on
>> Tuesday.
>
> I see that it is too late now, but let me still note that the
> taskjuggler exporter is quite liberal in what attribute values it allows
> for exporting. I've never used it and I haven't ever seen anyone using
> it, but in theory you could give a task a note or a journalentry which
> spans multiple lines. This will no longer be possible with this change.
>
> I guess if anyone ever wants to specify notes and journalentries for a
> task and export this to taskjuggler they will have to put it on one
> line.

I use this, or at least things like this. For example:

* task
    :PROPERTIES:
    :start:    2014-11-03-08:00
    :task_id:  task_d
    :depends: task_a task_b task_c
    :duration: 30min
    :END:

Not multi-line, but currently I can feed any property that matches a
tj3 attribute (e.g. "task_id") and Org will "do the right thing." I
haven't followed this thread, but wanted to chime in with my usage in
case it affects the discussion/considerations around this.


John

>
> Thanks
> Christian
> --
> Christian Egli
> Swiss Library for the Blind, Visually Impaired and Print Disabled
> Grubenstrasse 12, CH-8045 Zürich, Switzerland
>
>

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Christian Egli <christian.egli@sbs.ch> writes:

> I see that it is too late now, but let me still note that the
> taskjuggler exporter is quite liberal in what attribute values it allows
> for exporting. I've never used it and I haven't ever seen anyone using
> it, but in theory you could give a task a note or a journalentry which
> spans multiple lines. This will no longer be possible with this
> change.

I'm not sure to understand what is a note or a journalentry which spans
multiple lines. Could you give an example?


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Christian Egli]

John Hendy <jw.hendy@gmail.com> writes:

> I use this, or at least things like this. For example:
>
> * task
>     :PROPERTIES:
>     :start:    2014-11-03-08:00
>     :task_id:  task_d
>     :depends: task_a task_b task_c
>     :duration: 30min
>     :END:
>
> Not multi-line, but currently I can feed any property that matches a
> tj3 attribute (e.g. "task_id") and Org will "do the right thing."

This usage is perfectly fine and will continue to work. There are some
very obscure attributes that taskjuggler (and the exporter) support,
such as note and journalentry. These can span multiple lines. They can
be used to add notes or more structured "journal" entries. A
journalentry has several subparts (headline, summary, etc) but I don't
think we need to support this. IMHO the best "resolution" to this is to
simply take the two attributes note and journalentry out of the list of
exported attributes.

Or maybe better yet, add a note to the docstring. Maybe I'll just do
that.

Thanks
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Christian Egli <christian.egli@sbs.ch> writes:

> This usage is perfectly fine and will continue to work. There are some
> very obscure attributes that taskjuggler (and the exporter) support,
> such as note and journalentry. These can span multiple lines. They can
> be used to add notes or more structured "journal" entries. A
> journalentry has several subparts (headline, summary, etc) but I don't
> think we need to support this. IMHO the best "resolution" to this is to
> simply take the two attributes note and journalentry out of the list of
> exported attributes.

I still don't get how a journalentry or a note spanning multiple lines
look like.

Org doesn't support multi line properties. But this could be a drawer or
a block.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Christian Egli]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Christian Egli <christian.egli@sbs.ch> writes:
>
>> I see that it is too late now, but let me still note that the
>> taskjuggler exporter is quite liberal in what attribute values it allows
>> for exporting. I've never used it and I haven't ever seen anyone using
>> it, but in theory you could give a task a note or a journalentry which
>> spans multiple lines. This will no longer be possible with this
>> change.
>
> I'm not sure to understand what is a note or a journalentry which spans
> multiple lines. Could you give an example?

Speaking in taskjuggler syntax it would be as follows:

task alpha "Alpha Test" {
      effort 1w
      depends !!software
      allocate test, dev2
      note "Hopefully most bugs will be found and fixed here."
      journalentry 2002-03-01 "Contract with Peter not yet signed" {
        author boss
        alert red
        summary -8<-
          The paperwork is stuck with HR and I can't hunt it down.
        ->8-
        details -8<-
          If we don't get the contract closed within the next week,
          the start of the testing is at risk.
        ->8-
      }
    }

AFAIK the org-mode taskjuggler exporter was previously able to handle
this if given the following headline:

* task
    :PROPERTIES:
    :Effort:  1w
    :depends: software
    :allocate: test dev2
    :note: "Hopefully most bugs will be found and fixed here."
    :journalentry: 2002-03-01 "Contract with Peter not yet signed" {
        author boss
        alert red
        summary -8<-
          The paperwork is stuck with HR and I can't hunt it down.
        ->8-
        details -8<-
          If we don't get the contract closed within the next week,
          the start of the testing is at risk.
        ->8-
      }
    :END:

Oh, and btw: there can be more than one journalentry. So, given this
taskjuggler feature is not very often used and drawer machinery is not
really suited for this use case I suggest we just drop support for it.
Maybe the user can just squeeze the whole entry on one line interspersed
with \ns.

Thanks
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Christian Egli <christian.egli@sbs.ch> writes:

> AFAIK the org-mode taskjuggler exporter was previously able to handle
> this if given the following headline:
>
> * task
>     :PROPERTIES:
>     :Effort:  1w
>     :depends: software
>     :allocate: test dev2
>     :note: "Hopefully most bugs will be found and fixed here."
>     :journalentry: 2002-03-01 "Contract with Peter not yet signed" {
>         author boss
>         alert red
>         summary -8<-
>           The paperwork is stuck with HR and I can't hunt it down.
>         ->8-
>         details -8<-
>           If we don't get the contract closed within the next week,
>           the start of the testing is at risk.
>         ->8-
>       }
>     :END:

I'm surprised it worked. Anyway, you're right, it will not anymore.

> Oh, and btw: there can be more than one journalentry. So, given this
> taskjuggler feature is not very often used and drawer machinery is not
> really suited for this use case I suggest we just drop support for it.
> Maybe the user can just squeeze the whole entry on one line interspersed
> with \ns.

I think a #+begin_journalentry ... #+end_journalentry with proper
attributes would be enough.


Regards,

Re: [RFC] Change property drawer syntax

[Sebastien Vauban]

Nicolas Goaziou wrote:
> Nicolas Goaziou <mail-Gpy5sJQTEQHwkn9pgDnJRVAUjnlXr6A1@public.gmane.org> writes:
>
>>> As discussed previously, I would like to modify property drawers syntax.
>>> The change is simple: they must be located right after a headline and
>>> its planning line, if any.
>>
>> [...]
>>
>>> I pushed a new branch, "top-properties" in the repository for code
>>> review and testing. It includes unit tests, documentation and an
>>> ORG-NEWS entry.
>
>> If there is no more feedback or objection, I will merge the branch on
>> Tuesday.
>
> Done.

Thanks for this (and, moreover, for your very handy repair function!).

One question, now that this syntax is stabilized, can the following
long-standing bug be fixed: sometimes the SCHEDULED line (or DEADLINE,
or ...) is moved synchronously with the heading when promoting/demoting,
sometimes not.

I found in which cases it does and when it does not: it depends on the
presence of text in the entry.

So, for example:

--8<---------------cut here---------------start------------->8---
* The SCHED will be moved
  SCHEDULED: <2011-08-18 Thu>

* This one won't be moved along with the heading
  SCHEDULED: <2011-08-18 Thu>

Because of this text here...
--8<---------------cut here---------------end--------------->8---

becomes, when *demoted*:

--8<---------------cut here---------------start------------->8---
* New section

** The SCHED will be moved
   SCHEDULED: <2011-08-18 Thu>

** This one won't be moved along with the heading
  SCHEDULED: <2011-08-18 Thu>

Because of this text here...
--8<---------------cut here---------------end--------------->8---

This had been fixed by Bastien in August 2011, but the fix had reverted
afterward.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> One question, now that this syntax is stabilized, can the following
> long-standing bug be fixed: sometimes the SCHEDULED line (or DEADLINE,
> or ...) is moved synchronously with the heading when promoting/demoting,
> sometimes not.
>
> I found in which cases it does and when it does not: it depends on the
> presence of text in the entry.
>
> So, for example:
>
> --8<---------------cut here---------------start------------->8---
> * The SCHED will be moved
>   SCHEDULED: <2011-08-18 Thu>
>
> * This one won't be moved along with the heading
>   SCHEDULED: <2011-08-18 Thu>
>
> Because of this text here...
> --8<---------------cut here---------------end--------------->8---
>
> becomes, when *demoted*:
>
> --8<---------------cut here---------------start------------->8---
> * New section
>
> ** The SCHED will be moved
>    SCHEDULED: <2011-08-18 Thu>
>
> ** This one won't be moved along with the heading
>   SCHEDULED: <2011-08-18 Thu>
>
> Because of this text here...
> --8<---------------cut here---------------end--------------->8---
>
> This had been fixed by Bastien in August 2011, but the fix had reverted
> afterward.

I pushed a change that should make indentation shift hopefully smarter.

Thank you for reminding me about this.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> One question, now that this syntax is stabilized, can the following
>> long-standing bug be fixed: sometimes the SCHEDULED line (or
>> DEADLINE, or ...) is moved synchronously with the heading when
>> promoting/demoting, sometimes not.
>>
>> I found in which cases it does and when it does not: it depends on
>> the presence of text in the entry.
>>
>> So, for example:
>>
>> --8<---------------cut here---------------start------------->8---
>> * The SCHED will be moved
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> * This one won't be moved along with the heading
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> Because of this text here...
>> --8<---------------cut here---------------end--------------->8---
>>
>> becomes, when *demoted*:
>>
>> --8<---------------cut here---------------start------------->8---
>> * New section
>>
>> ** The SCHED will be moved
>>    SCHEDULED: <2011-08-18 Thu>
>>
>> ** This one won't be moved along with the heading
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> Because of this text here...
>> --8<---------------cut here---------------end--------------->8---
>>
>> This had been fixed by Bastien in August 2011, but the fix had reverted
>> afterward.
>
> I pushed a change that should make indentation shift hopefully smarter.

It does work perfectly on the "meta-stuff" (SCHEDULED, DEADLINE,
etc.). Though, it moves as well the "body" text -- while I'm not using
`org-indent-mode'.

--8<---------------cut here---------------start------------->8---
* New section

* The SCHED will be moved
  SCHEDULED: <2011-08-18 Thu>

** This one won't be moved along with the heading
   SCHEDULED: <2011-08-18 Thu>

 Because of this text here...
--8<---------------cut here---------------end--------------->8---
^ Space inserted here.

See http://screencast.com/t/2AkkSTpqe5.

> Thank you for reminding me about this.

Thanks to you for your continuous support!  We don't say it enough ;-(

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> It does work perfectly on the "meta-stuff" (SCHEDULED, DEADLINE,
> etc.). Though, it moves as well the "body" text -- while I'm not using
> `org-indent-mode'.
>
> * New section
>
> * The SCHED will be moved
>   SCHEDULED: <2011-08-18 Thu>
>
> ** This one won't be moved along with the heading
>    SCHEDULED: <2011-08-18 Thu>
>
>  Because of this text here...
> ^ Space inserted here.

This is expected, actually. I realize that `org-adapt-indentation'
docstring is not totally up-to-date.

If your indentation shouldn't depend on the current headline level, you
might want to set this variable to nil.


Regards,

Re: [RFC] Change property drawer syntax

[Sebastien Vauban]

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> It does work perfectly on the "meta-stuff" (SCHEDULED, DEADLINE,
>> etc.). Though, it moves as well the "body" text -- while I'm not using
>> `org-indent-mode'.
>>
>> * New section
>>
>> * The SCHED will be moved
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> ** This one won't be moved along with the heading
>>    SCHEDULED: <2011-08-18 Thu>
>>
>>  Because of this text here...
>> ^ Space inserted here.
>
> This is expected, actually. I realize that `org-adapt-indentation'
> docstring is not totally up-to-date.
>
> If your indentation shouldn't depend on the current headline level,

Yes, that's what I want [1]!

> you might want to set this variable to nil.

Isn't that somehow duplicate with `org-indent-mode' (which I don't
enable either)?

  ┌────
  │ org-indent-mode is an interactive autoloaded Lisp function in `org-indent.el'.
  │ 
  │ (org-indent-mode &optional ARG)
  │ 
  │ When active, indent text according to outline structure.
  │ 
  │ Internally this works by adding `line-prefix' and `wrap-prefix'
  │ properties, after each buffer modification, on the modified zone.
  │ 
  │ The process is synchronous.  Though, initial indentation of
  │ buffer, which can take a few seconds on large buffers, is done
  │ during idle time.
  └────

Would I want to let the indentation following the level of the entries,
I'm not sure what I'd have to do:

- (org-indent-mode), and/or
- (setq org-adapt-indentation t)?

Best regards,
  Seb

[1] And that simplifies A LOT file diffs...

    Hence, another question: shouldn't the default be reversed (no
    adaption of indentation, by default)?

-- 
Sebastien Vauban

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> Isn't that somehow duplicate with `org-indent-mode' (which I don't
> enable either)?

`org-indent-mode' sets `org-adapt-indentation' to nil _and_ indents
virtually (no modification to the document) body as if
`org-adapt-indentation' wasn't nil.

There's no duplication here.

> Would I want to let the indentation following the level of the entries,
> I'm not sure what I'd have to do:
>
> - (org-indent-mode), and/or
> - (setq org-adapt-indentation t)?

I cannot decide for you. But editing will certainly be snappier without
`org-indent-mode' active.

> [1] And that simplifies A LOT file diffs...
>
>     Hence, another question: shouldn't the default be reversed (no
>     adaption of indentation, by default)?

I like the current default. However I don't mind changing it if it is
very uncommon among users to set it to a non-nil value. 

Note that it doesn't appear in
<http://orgmode.org/worg/org-configs/org-customization-survey.html>.
Admittedly, the survey is outdated.

Regards,

Re: [RFC] Change property drawer syntax

[Sebastien Vauban]

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> Isn't that somehow duplicate with `org-indent-mode' (which I don't
>> enable either)?
>
> `org-indent-mode' sets `org-adapt-indentation' to nil _and_ indents
> virtually (no modification to the document) body as if
> `org-adapt-indentation' wasn't nil.
>
> There's no duplication here.

Very clear, thank you.

>> Would I want to let the indentation following the level of the entries,
>> I'm not sure what I'd have to do:
>>
>> - (org-indent-mode), and/or
>> - (setq org-adapt-indentation t)?
>
> I cannot decide for you. But editing will certainly be snappier without
> `org-indent-mode' active.

I don't want neither physical nor virtual adaptation of the
indentation. My question was for the purpose of understanding more.

>> [1] And that simplifies A LOT file diffs...
>>
>>     Hence, another question: shouldn't the default be reversed (no
>>     adaption of indentation, by default)?
>
> I like the current default. However I don't mind changing it if it is
> very uncommon among users to set it to a non-nil value. 

For me, choosing one over the other is a question of taste, and can't be
debated as such. Here, though, as adapting the indentation complexifies
all diffs between different versions of the file, yes, I'd choose for
the "simpler" road as the default for the Org beginners.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Change property drawer syntax

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> It does work perfectly on the "meta-stuff" (SCHEDULED, DEADLINE,
>> etc.). Though, it moves as well the "body" text -- while I'm not
>> using `org-indent-mode'.
>>
>> * New section
>>
>> ** The SCHED will be moved
>>    SCHEDULED: <2011-08-18 Thu>
>>
>> ** This one won't be moved along with the heading
>>   SCHEDULED: <2011-08-18 Thu>
>>
>>  Because of this text here...
>> ^ Space inserted here.
>
> This is expected, actually. I realize that `org-adapt-indentation'
> docstring is not totally up-to-date.
>
> If your indentation shouldn't depend on the current headline level,
> you might want to set this variable to nil.

I've done that but, now, it does not support anymore the structure I had
in all my Org files:

--8<---------------cut here---------------start------------->8---
** TODO Show typical Org entry
   SCHEDULED: <2014-11-08 Sat>
   :LOGBOOK:
   CLOCK: [2014-11-11 Tue 12:35]--[2014-11-11 Tue 14:19] =>  1:44
   :END:

I have the planning lines and the drawers indented at the level of the
entry.

On the other hand, the "body text" of the entry always begins at
column 0.  This makes a clear distinction between "meta-stuff" and the
contents of the entry itself.
--8<---------------cut here---------------end--------------->8---

Now, with `org-adapt-indentation' set to `t', the whole "block" moves to
the right when demoting, and to the left (except for the LOGBOOK
drawer!? [1]) when promoting.

With `org-adapt-indentation' set to `nil', nothing moves (but the
headline), when demoting or promoting.

Thanks for your help.

Best regards,
  Seb

[1] See http://screencast.com/t/nsGNuoHL.

-- 
Sebastien Vauban

Re: [RFC] Change property drawer syntax

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> As discussed previously, I would like to modify property drawers
> syntax. [...]
>
> However, it will break some Org documents. In particular, TODO-states
> changes are usually logged before any drawer, including properties
> drawers. The following function repairs them.
>
>   (defun org-repair-property-drawers ()
>     "Fix properties drawers in current buffer.
>   Ignore non Org buffers."
>     (when (eq major-mode 'org-mode)
>       (org-with-wide-buffer
>        (goto-char (point-min))
>        (let ((case-fold-search t)
>              (inline-re (and (featurep 'org-inlinetask)
>                              (concat (org-inlinetask-outline-regexp)
>                                      "END[ \t]*$"))))
>          (org-map-entries
>           (lambda ()
>             (unless (and inline-re (org-looking-at-p inline-re))
>               (save-excursion
>                 (let ((end (save-excursion (outline-next-heading) (point))))
>                   (forward-line)
>                   (when (org-looking-at-p org-planning-line-re) (forward-line))
>                   (when (and (< (point) end)
>                              (not (org-looking-at-p org-property-drawer-re))
>                              (save-excursion
>                                (re-search-forward org-property-drawer-re end t)))
>                     (insert (delete-and-extract-region
>                              (match-beginning 0)
>                              (min (1+ (match-end 0)) end)))
>                     (unless (bolp) (insert "\n"))))))))))))

After heavy testing (on all my Org files, I mean) of the above function,
it works perfectly except for the following corner-case (when there are
Org properties in "quote" blocks):

--8<---------------cut here---------------start------------->8---
* Reference

Example of Custom ID:

#+begin_verse
,* Some title
  :PROPERTIES:
  :CUSTOM_ID: SomeTitle
  :END:

Lorem ipsum
#+end_verse
--8<---------------cut here---------------end--------------->8---

will be converted to:

--8<---------------cut here---------------start------------->8---
* Reference
  :PROPERTIES:
  :CUSTOM_ID: SomeTitle
  :END:

Example of Custom ID:

#+begin_verse
,* Some title

Lorem ipsum
#+end_verse
--8<---------------cut here---------------end--------------->8---

upon execution of `org-repair-property-drawers'.

PS- I did not retest (yet) the same thing in #+begin/end_src
    blocks... as playing with that example files makes my Emacs eat 100%
    of the CPU (infloop?). I've restarted Emacs 5 or 6 times before
    being able to write this ECM...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Change property drawer syntax

[Sebastien Vauban]

Nicolas,

Sebastien Vauban wrote:
> After heavy testing (on all my Org files, I mean) of the function
> `org-repair-property-drawers', it works perfectly except for the
> following corner-case (when there are Org properties in "quote"
> blocks).
>
> PS- I did not retest (yet) the same thing in #+begin/end_src
>     blocks... as playing with that example files makes my Emacs eat 100%
>     of the CPU (infloop?). I've restarted Emacs 5 or 6 times before
>     being able to write this ECM...

I confirm the problem is the same if Org properties are enclosed in
a #+begin/end_src block such as:

--8<---------------cut here---------------start------------->8---
** Sectionnement

Exemple de section avec un titre court pour LaTeX :

#+begin_src org
,* Ceci est un titre de section assez long
  :PROPERTIES:
  :ALT_TITLE: Ceci est un titre court
  :END:
#+end_src
--8<---------------cut here---------------end--------------->8---

Upon execution of the repair function, that entry will be wrongly
converted.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> I've done that but, now, it does not support anymore the structure I had
> in all my Org files:
>
> ** TODO Show typical Org entry
>    SCHEDULED: <2014-11-08 Sat>
>    :LOGBOOK:
>    CLOCK: [2014-11-11 Tue 12:35]--[2014-11-11 Tue 14:19] =>  1:44
>    :END:
>
> I have the planning lines and the drawers indented at the level of the
> entry.
>
> On the other hand, the "body text" of the entry always begins at
> column 0.  This makes a clear distinction between "meta-stuff" and the
> contents of the entry itself.

This distinction is not known by Org. 

"Meta-stuff" is stuff bound to a headline: planning info and, now,
properties drawer. OTOH, a LOGBOOK drawer is a regular drawer, which can
be inserted anywhere within the section. As such, it belong to the body
of the section.

> Now, with `org-adapt-indentation' set to `t', the whole "block" moves to
> the right when demoting, and to the left (except for the LOGBOOK
> drawer!? [1]) when promoting.

When demoting, everything, i.e., "meta-stuff" and body, is moved to the
right. When promoting, "meta-stuff" is moved unconditionally (due to
`org-adapt-indentation'), but line beginning at column 0 prevents the
body from being moved.

Maybe behaviour could be more symmetric (i.e., refuse to demote body if
promoting it would fail). I didn't think about it much, but I have the
feeling that there are pitfalls, however.

`org-adapt-indentation' is really useful if you indent everything, e.g.,
using C-j to start new lines. Here you are using something in-between.
I suggest to keep `org-adapt-indentation' to nil and "fix" meta stuff
and logbook by indentation by hand, using `org-after-demote-entry-hook'
and `org-after-promote-entry-hook'.

> With `org-adapt-indentation' set to `nil', nothing moves (but the
> headline), when demoting or promoting.

This sounds right.

> [1] See http://screencast.com/t/nsGNuoHL.

This requires Flash, which I don't have.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> After heavy testing (on all my Org files, I mean) of the above function,
> it works perfectly except for the following corner-case (when there are
> Org properties in "quote" blocks):
>
> * Reference
>
> Example of Custom ID:
>
> #+begin_verse
> ,* Some title
>   :PROPERTIES:
>   :CUSTOM_ID: SomeTitle
>   :END:
>
> Lorem ipsum
> #+end_verse
>
> will be converted to:
>
> * Reference
>   :PROPERTIES:
>   :CUSTOM_ID: SomeTitle
>   :END:
>
> Example of Custom ID:
>
> #+begin_verse
> ,* Some title
>
> Lorem ipsum
> #+end_verse
>
> upon execution of `org-repair-property-drawers'.

Thanks for your feedback. Would the following updated function solve the
problem?

  (defun org-repair-property-drawers ()
    "Fix properties drawers in current buffer.
  Ignore non Org buffers."
    (when (eq major-mode 'org-mode)
      (org-with-wide-buffer
       (goto-char (point-min))
       (let ((case-fold-search t)
             (inline-re (and (featurep 'org-inlinetask)
                             (concat (org-inlinetask-outline-regexp)
                                     "END[ \t]*$"))))
         (org-map-entries
          (lambda ()
            (unless (and inline-re (org-looking-at-p inline-re))
              (save-excursion
                (let ((end (save-excursion (outline-next-heading) (point))))
                  (forward-line)
                  (when (org-looking-at-p org-planning-line-re) (forward-line))
                  (when (and (< (point) end)
                             (not (org-looking-at-p org-property-drawer-re))
                             (save-excursion
                               (re-search-forward org-property-drawer-re end t)
                               (eq (org-element-type
                                    (save-match-data (org-element-at-point)))
                                   'drawer)))
                    (insert (delete-and-extract-region
                             (match-beginning 0)
                             (min (1+ (match-end 0)) end)))
                    (unless (bolp) (insert "\n"))))))))))))

> PS- I did not retest (yet) the same thing in #+begin/end_src
>     blocks... as playing with that example files makes my Emacs eat 100%
>     of the CPU (infloop?).

Could you provide an ECM for that?


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> After heavy testing (on all my Org files, I mean) of the above function,
>> it works perfectly except for the following corner-case [...].
>
> Thanks for your feedback. Would the following updated function solve the
> problem?
>
>   (defun org-repair-property-drawers ()
>     "Fix properties drawers in current buffer.
>   Ignore non Org buffers."
>     (when (eq major-mode 'org-mode)
>       (org-with-wide-buffer
>        (goto-char (point-min))
>        (let ((case-fold-search t)
>              (inline-re (and (featurep 'org-inlinetask)
>                              (concat (org-inlinetask-outline-regexp)
>                                      "END[ \t]*$"))))
>          (org-map-entries
>           (lambda ()
>             (unless (and inline-re (org-looking-at-p inline-re))
>               (save-excursion
>                 (let ((end (save-excursion (outline-next-heading) (point))))
>                   (forward-line)
>                   (when (org-looking-at-p org-planning-line-re) (forward-line))
>                   (when (and (< (point) end)
>                              (not (org-looking-at-p org-property-drawer-re))
>                              (save-excursion
>                                (re-search-forward org-property-drawer-re end t)
>                                (eq (org-element-type
>                                     (save-match-data (org-element-at-point)))
>                                    'drawer)))
>                     (insert (delete-and-extract-region
>                              (match-beginning 0)
>                              (min (1+ (match-end 0)) end)))
>                     (unless (bolp) (insert "\n"))))))))))))

Nope, this one really breaks my Org file. For example:

--8<---------------cut here---------------start------------->8---
#+TITLE: Xxxxx Xxxxxx
#+AUTHOR: Xxxxxxx Xxxxxxx
#+EMAIL: xxx-XsV/KxTKYItexX8rFMpgi3AlXr9lQLeu@public.gmane.org
#+LANGUAGE: xx

#+FILETAGS: :xxxx:xxxxx:

* Xxxxxx

** Xxxx xxxx "Xxxxxxxxxxx xxx xxxxxxx xxxxxxx - Xxxxxx xx xxxxxxxxxx xxx xxxxxxxx"
   <2014-10-09 Thu 10:00>

Xxxxxxx: Xxxxxxxx xx Xxxxxx (Xxxxxx XX).

* Xxxxx

** CANX Xxxx xxxxxxxx xxxxxxxxxxx xx xxxxxxxxxxx (xxxx Xxxxxx Xxxxxx Xxxxxxx)
   DEADLINE: <2014-10-08 Wed>
   :LOGBOOK:
   - Xxxxx "XXXX"        ->  "XXXX"       [2014-10-09 Thu 18:18]
   :END:
   [2014-09-30 Tue 11:18]

#+BEGIN_VERSE
Xxxxxx xxxxx xx xxxx xxxxx xxx xxxxxxxxxx. Xxxx xxxx x xxxxxxx:

- Xxxx x xxxx xxxx xx xxxxxxxx xxxxxxxxxx
- Xx x xxxxxxx
- Xxxxx xxxxx xxx xxxx

Xx xx xxxxxxxx, xx xxxx:

x Xxxxxxxxxx xxxxxxxxxxx xx xxxxxxxxxxx (xxx xx xxxx xxxx)
x Xxxxxxxx xxxxxxxxxxx xx xxxxxxxxxxx (xxx xxxxxxxxx xx xxxxx? xxxxxxxx?…)
x Xxxx xxx xx xxxx xxxx xxxx'x xxxx xxxx xx xx xxxxxxxxxxx?
x Xxxxxxxxxx "xxxxxxxxx xxxx" xx xxx

Xxxxx xxx xxxx xxxx xx (x) xxx (x)?
#+END_VERSE

Xxxx [[http://orgmode.org][Xxxxx xxxx Xxxxxx Xxxxxx Xxxxxxx: {xxx} Xxx: Xxxx x xxxx xxxxxxx]]
--8<---------------cut here---------------end--------------->8---

becomes:

--8<---------------cut here---------------start------------->8---
#+TITLE: Xxxxx Xxxxxx
#+AUTHOR: Xxxxxxx Xxxxxxx
#+EMAIL: xxx-XsV/KxTKYItexX8rFMpgi3AlXr9lQLeu@public.gmane.org
#+LANGUAGE: xx

#+FILETAGS: :xxxx:xxxxx:

* Xxxxxx

** Xxxx xxxx "Xxxxxxxxxxx xxx xxxxxxx xxxxxxx - Xxxxxx xx xxxxxxxxxx xxx xxxxxxxx"
   <2014-10-09 Thu 10:00>

Xxxxxxx: Xxxxxxxx xx Xxxxxx (Xxxxxx XX).

* Xxxxx

ANX Xxxx xxxxxxxx xxxxxxxxxxx xx xxxxxxxxxxx (xxxx Xxxxxx Xxxxxx Xxxxxxx)
   DEADLINE: <2014-10-08 Wed>



** C
   :LOGBOOK:
   - Xxxxx "XXXX"        ->  "XXXX"       [2014-10-09 Thu 18:18]
   :END:
   [2014-09-30 Tue 11:18]

#+BEGIN_VERSE
Xxxxxx xxxxx xx xxxx xxxxx xxx xxxxxxxxxx. Xxxx xxxx x xxxxxxx:

- Xxxx x xxxx xxxx xx xxxxxxxx xxxxxxxxxx
- Xx x xxxxxxx
- Xxxxx xxxxx xxx xxxx

Xx xx xxxxxxxx, xx xxxx:

x Xxxxxxxxxx xxxxxxxxxxx xx xxxxxxxxxxx (xxx xx xxxx xxxx)
x Xxxxxxxx xxxxxxxxxxx xx xxxxxxxxxxx (xxx xxxxxxxxx xx xxxxx? xxxxxxxx?…)
x Xxxx xxx xx xxxx xxxx xxxx'x xxxx xxxx xx xx xxxxxxxxxxx?
x Xxxxxxxxxx "xxxxxxxxx xxxx" xx xxx

Xxxxx xxx xxxx xxxx xx (x) xxx (x)?
#+END_VERSE

Xxxx [[http://orgmode.org][Xxxxx xxxx Xxxxxx Xxxxxx Xxxxxxx: {xxx} Xxx: Xxxx x xxxx xxxxxxx]]
--8<---------------cut here---------------end--------------->8---

Observe that:
- many blank lines are added,
- the TODO keyword (CANX) is broken, and
- a new task is created.

>> PS- I did not retest (yet) the same thing in #+begin/end_src
>>     blocks... as playing with that example files makes my Emacs eat 100%
>>     of the CPU (infloop?).
>
> Could you provide an ECM for that?

It really was just editing the given example. So, this file:

--8<---------------cut here---------------start------------->8---
* Reference

Example of Custom ID:

#+begin_verse
,* Some title
  :PROPERTIES:
  :CUSTOM_ID: SomeTitle
  :END:

Lorem ipsum
#+end_verse
--8<---------------cut here---------------end--------------->8---

caused me trouble with the initial `org-repair-property-drawers' added
to the `org-mode-hook'!?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Change property drawer syntax

[Sebastien Vauban]

Hello Nicoalas,

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> I've done that but, now, it does not support anymore the structure I had
>> in all my Org files:
>>
>> ** TODO Show typical Org entry
>>    SCHEDULED: <2014-11-08 Sat>
>>    :LOGBOOK:
>>    CLOCK: [2014-11-11 Tue 12:35]--[2014-11-11 Tue 14:19] =>  1:44
>>    :END:
>>
>> I have the planning lines and the drawers indented at the level of the
>> entry.
>>
>> On the other hand, the "body text" of the entry always begins at
>> column 0.  This makes a clear distinction between "meta-stuff" and the
>> contents of the entry itself.
>
> This distinction is not known by Org. 
>
> "Meta-stuff" is stuff bound to a headline: planning info and, now,
> properties drawer. OTOH, a LOGBOOK drawer is a regular drawer, which can
> be inserted anywhere within the section. As such, it belong to the body
> of the section.

Would it be a problem to bind the LOGBOOK drawer to the headline as
well (like you did for the PROPERTIES drawer)?

>> Now, with `org-adapt-indentation' set to `t', the whole "block" moves to
>> the right when demoting, and to the left when promoting.
>
> When demoting, everything, i.e., "meta-stuff" and body, is moved to the
> right. When promoting, "meta-stuff" is moved unconditionally (due to
> `org-adapt-indentation'), but line beginning at column 0 prevents the
> body from being moved.
>
> `org-adapt-indentation' is really useful if you indent everything, e.g.,
> using C-j to start new lines. Here you are using something in-between.

Did not know I wasn't conforming to the common habits...

From what I've seen,

- Planning info and drawers are typically "indented" (see Worg, the
  Org-mode manual and http://doc.norang.ca/org-mode.html for different
  types of drawers, sometimes including the PROPERTIES one), what makes
  those info stand out from the "notes" themselves.

- Body text is often not indented (see Worg files themselves), which is
  much easier for diffing different versions of the same file).

> I suggest to keep `org-adapt-indentation' to nil

OK.

> and "fix" meta stuff and logbook by indentation by hand, using
> `org-after-demote-entry-hook' and `org-after-promote-entry-hook'.

That could do it when promoting or demoting entries.  But that's not
sufficient: now, whenever logging a state change (from TODO to DONE, for
example), a drawer gets created in column 0, instead of at the right
indentation level of the headline.

The same kind of problems occurred with a repeating timestamp:

--8<---------------cut here---------------start------------->8---
** TODO Noter les index de consommation
   DEADLINE: <2014-11-23 Sun 20:00 ++7d -0d>
   :PROPERTIES:
   :LAST_REPEAT: [2014-11-25 Tue 16:46]
   :END:
   :LOGBOOK:
   (...)
   - State "DONE"       from "TODO"       [2014-11-17 Mon 13:36]
   :END:
--8<---------------cut here---------------end--------------->8---

became (after C-c C-t d):

--8<---------------cut here---------------start------------->8---
** TODO Noter les index de consommation
DEADLINE: <2014-11-30 Sun 20:00 ++7d -0d>
   :PROPERTIES:
   :LAST_REPEAT: [2014-11-25 Tue 16:46]
   :END:
   :LOGBOOK:
   (...)
   - State "DONE"       from "TODO"       [2014-11-17 Mon 13:36]
   - State "DONE"       from "TODO"       [2014-11-25 Tue 16:46]
   :END:
--8<---------------cut here---------------end--------------->8---

^ DEADLINE in column 0.

Am I missing something?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Change property drawer syntax

[Sebastien Vauban]

Nicolas,

Sebastien Vauban wrote:
> Sebastien Vauban wrote:
>> After heavy testing (on all my Org files, I mean) of the function
>> `org-repair-property-drawers', it works perfectly except for the
>> following corner-case (when there are Org properties in "quote"
>> blocks).
>>
>> I did not retest (yet) the same thing in #+begin/end_src blocks...
>
> I confirm the problem is the same if Org properties are enclosed in
> a #+begin/end_src block such as:
>
> ** Sectionnement
>
> Exemple de section avec un titre court pour LaTeX :
>
> #+begin_src org
> ,* Ceci est un titre de section assez long
>   :PROPERTIES:
>   :ALT_TITLE: Ceci est un titre court
>   :END:
> #+end_src
>
> Upon execution of the repair function, that entry will be wrongly
> converted.

Do you experience the same problem as me?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

>> ** Sectionnement
>>
>> Exemple de section avec un titre court pour LaTeX :
>>
>> #+begin_src org
>> ,* Ceci est un titre de section assez long
>>   :PROPERTIES:
>>   :ALT_TITLE: Ceci est un titre court
>>   :END:
>> #+end_src
>>
>> Upon execution of the repair function, that entry will be wrongly
>> converted.
>
> Do you experience the same problem as me?

I do. I even sent you an updated revision of the repair function a few
days ago, but, apparently, it never reached its destination. This is not
the first time. Here it is again

  (defun org-repair-property-drawers ()
    "Fix properties drawers in current buffer.
  Ignore non Org buffers."
    (when (eq major-mode 'org-mode)
      (org-with-wide-buffer
       (goto-char (point-min))
       (let ((case-fold-search t)
             (inline-re (and (featurep 'org-inlinetask)
                             (concat (org-inlinetask-outline-regexp)
                                     "END[ \t]*$"))))
         (org-map-entries
          (lambda ()
            (unless (and inline-re (org-looking-at-p inline-re))
              (save-excursion
                (let ((end (save-excursion (outline-next-heading) (point))))
                  (forward-line)
                  (when (org-looking-at-p org-planning-line-re) (forward-line))
                  (when (and (< (point) end)
                             (not (org-looking-at-p org-property-drawer-re))
                             (save-excursion
                               (and (re-search-forward org-property-drawer-re end t)
                                    (eq (org-element-type
                                         (save-match-data (org-element-at-point)))
                                        'drawer))))
                    (insert (delete-and-extract-region
                             (match-beginning 0)
                             (min (1+ (match-end 0)) end)))
                    (unless (bolp) (insert "\n"))))))))))))

Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>>> ** Sectionnement
>>>
>>> Exemple de section avec un titre court pour LaTeX :
>>>
>>> #+begin_src org
>>> ,* Ceci est un titre de section assez long
>>>   :PROPERTIES:
>>>   :ALT_TITLE: Ceci est un titre court
>>>   :END:
>>> #+end_src
>>>
>>> Upon execution of the repair function, that entry will be wrongly
>>> converted.
>>
>> Do you experience the same problem as me?
>
> I do. I even sent you an updated revision of the repair function a few
> days ago, but, apparently, it never reached its destination. This is not
> the first time. Here it is again
>
>   (defun org-repair-property-drawers ()
>     "Fix properties drawers in current buffer.
>   Ignore non Org buffers."
>     (when (eq major-mode 'org-mode)
>       (org-with-wide-buffer
>        (goto-char (point-min))
>        (let ((case-fold-search t)
>              (inline-re (and (featurep 'org-inlinetask)
>                              (concat (org-inlinetask-outline-regexp)
>                                      "END[ \t]*$"))))
>          (org-map-entries
>           (lambda ()
>             (unless (and inline-re (org-looking-at-p inline-re))
>               (save-excursion
>                 (let ((end (save-excursion (outline-next-heading) (point))))
>                   (forward-line)
>                   (when (org-looking-at-p org-planning-line-re) (forward-line))
>                   (when (and (< (point) end)
>                              (not (org-looking-at-p org-property-drawer-re))
>                              (save-excursion
>                                (and (re-search-forward org-property-drawer-re end t)
>                                     (eq (org-element-type
>                                          (save-match-data (org-element-at-point)))
>                                         'drawer))))
>                     (insert (delete-and-extract-region
>                              (match-beginning 0)
>                              (min (1+ (match-end 0)) end)))
>                     (unless (bolp) (insert "\n"))))))))))))

The above function is perfect for her task!  No diff at all [1] when
applied on all my files from org-agenda-files (~ 45).

Best regards,
  Seb

[1] Except the localization of the property drawer, of course.

-- 
Sebastien Vauban

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> The above function is perfect for her task!  No diff at all [1] when
> applied on all my files from org-agenda-files (~ 45).

I updated ORG-NEWS then. Thanks for the feedback.


Regards,

Re: [RFC] Change property drawer syntax

[Puneeth Chaganti]

Hi Nicolas,

It looks the commit 8d8ad983823c63b13fd6b471ce9db8c2f95e3808 broke
generation of org sparse trees, when searching with properties that
are not all uppercase.   The fix seems to be just removing the
conversion of key to upcase in `org-entry-properties'.  Since the
comparison with special properties is being done by a case insensitive
check, this should be the only fix required?  There are no test
failures, and the conversion to uppercase seems to have been
introduced only in this change, so it should be OK?

diff --git a/lisp/org.el b/lisp/org.el
index e806440..8cbbcc4 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15703,7 +15703,7 @@ strings."
                    ;; after its extension.  We also forbid standard
                    ;; properties to be named as special properties.
                    (while (re-search-forward org-property-re end t)
-                     (let* ((key (upcase (org-match-string-no-properties 2)))
+                     (let* ((key (org-match-string-no-properties 2))
                             (extendp (org-string-match-p "\\+\\'" key))
                             (key-base (if extendp (substring key 0 -1) key))
                             (value (org-match-string-no-properties 3)))

Thanks,
Puneeth

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Hello,

Puneeth Chaganti <punchagan@gmail.com> writes:

> It looks the commit 8d8ad983823c63b13fd6b471ce9db8c2f95e3808 broke
> generation of org sparse trees, when searching with properties that
> are not all uppercase.

Could you provide an ECM?

> The fix seems to be just removing the conversion of key to upcase in
> `org-entry-properties'. Since the comparison with special properties
> is being done by a case insensitive check, this should be the only fix
> required?

There is another check, case-sensitive this time, for duplicate
properties just below.

Anyway, I think the problem lies in the fact that, somewhere in the
internals of the function generating the spare tree, there is
a case-sensitive search.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change property drawer syntax

[Puneeth Chaganti]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Sat, Dec 6, 2014 at 5:01 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Hello,
>
> Puneeth Chaganti <punchagan@gmail.com> writes:
>
>> It looks the commit 8d8ad983823c63b13fd6b471ce9db8c2f95e3808 broke
>> generation of org sparse trees, when searching with properties that
>> are not all uppercase.
>
> Could you provide an ECM?

I've attached the ECM.

>> The fix seems to be just removing the conversion of key to upcase in
>> `org-entry-properties'. Since the comparison with special properties
>> is being done by a case insensitive check, this should be the only fix
>> required?
>
> There is another check, case-sensitive this time, for duplicate
> properties just below.
>
> Anyway, I think the problem lies in the fact that, somewhere in the
> internals of the function generating the spare tree, there is
> a case-sensitive search.

Yes, that is correct.  I have a few code blocks that work and don't
work, in the ECM, if at all you want to look at them.

[-- Attachment #2: sparse-tree-ecm.org --]
[-- Type: application/octet-stream, Size: 790 bytes --]

* Classic
** Goldberg Variations
   :PROPERTIES:
   :Title:    Goldberg Variations
   :Composer: J.S. Bach
   :Artist:   Glen Gould
   :Publisher: Deutsche Grammophon
   :NDisks:   1
   :TEST:     1
   :END:

#+BEGIN_SRC emacs-lisp
  (org-match-sparse-tree nil "NDisks=\"1\"") ;; Does not work
  (org-match-sparse-tree nil "TEST=\"1\"")   ;; Works

  ;; The matcher created is
  (and (progn (setq org-cached-props nil) (string= (or (org-cached-entry-get nil "NDisks") "") "1")) t)
  ;; Cached entries have upcase tags and it doesn't work


  ;; This would work
  (and (progn (setq org-cached-props nil) (string= (or (org-cached-entry-get nil "NDISKS") "") "1")) t)

  ;; Also, this
  (and (progn (setq org-cached-props nil) (string= (or (org-entry-get nil "NDisks") "") "1")) t)

#+END_SRC

Re: [RFC] Change property drawer syntax

[Nicolas Goaziou]

Puneeth Chaganti <punchagan@gmail.com> writes:

> Yes, that is correct.  I have a few code blocks that work and don't
> work, in the ECM, if at all you want to look at them.

It should now be fixed. Thank you for reporting it.


Regards,