Patchwork [O] Possible bug in org-cycle with property drawer

Hi Nick,

Nick Dokos <nicholas.dokos@hp.com> writes:

> That's it: I had a 
>
> #+DRAWERS: JUNK GARBAGE TRASH
>
> line in the file (and I didn't report it in the original email: blush!
> sorry about that).  Without it, the property drawer behaves normally.

Thinking again about your problem, I don't find it natural to
have #+DRAWERS /replacing/ existing drawers specified in `org-drawers',
instead of just adding new ones.

Do you agree?

The attached patch implements a new meaning for #+DRAWERS, as a way
to declare "additional" drawers.

Let me know what you think, thanks!

Bastien <bzg@altern.org> wrote:

> Hi Nick,
> 
> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > That's it: I had a 
> >
> > #+DRAWERS: JUNK GARBAGE TRASH
> >
> > line in the file (and I didn't report it in the original email: blush!
> > sorry about that).  Without it, the property drawer behaves normally.
> 
> Thinking again about your problem, I don't find it natural to
> have #+DRAWERS /replacing/ existing drawers specified in `org-drawers',
> instead of just adding new ones.
> 
> Do you agree?
> 
> The attached patch implements a new meaning for #+DRAWERS, as a way
> to declare "additional" drawers.
> 
> Let me know what you think, thanks!
> 

If I've learnt anything from watching the list over the years, it's that
somebody will have a need to replace existing drawers, so be prepared
for that :-)

That said, I can't think of any reason why adding to existing drawers,
instead of replacing them, would lead to problems. So I'm inclined to
agree with you. One question that might arise: are multiple
#+DRAWERS lines legal? and if so, what do they do?

I'll try to take the patch for a spin but I'm not sure when I'll be able
to do it.

Thanks,
Nick

Bastien <bzg@altern.org> writes:
> Thinking again about your problem, I don't find it natural to
> have #+DRAWERS /replacing/ existing drawers specified in `org-drawers',
> instead of just adding new ones.

Well, if one had defined a lot of drawers in their configuration and
wanted the list to be trimmed in a few documents...

Personally I never customize org-drawer, based on the principle that
local configuration shouldn't render documents invalid in a different
environment.  Based on that principle, if you do configure the drawers
for a document, you should provide the complete list and not just some
additional configuration, so the current behaviour is perfect.  If you
change it, I'd now need a way to specify that I do not want to import
the local configuration.

I'd rather have an extension to #+KEYWORD to import their existing
global counterpart, where appropriate.


Regards,
Achim.

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien <bzg@altern.org> writes:
>> Thinking again about your problem, I don't find it natural to
>> have #+DRAWERS /replacing/ existing drawers specified in `org-drawers',
>> instead of just adding new ones.
>
> Well, if one had defined a lot of drawers in their configuration and
> wanted the list to be trimmed in a few documents...

This is quite a hypothetical case: the default value for `org-drawers'
contains drawers that are hardcoded and correspond to key features: I
cannot figure out a good reason for *not* having these drawers in the
configuration.

I applied the patch.

In case that's really a problem, we can have a variable
`org-default-drawers-persistent' or something.

Bastien <bzg@altern.org> writes:
> This is quite a hypothetical case: the default value for `org-drawers'
> contains drawers that are hardcoded and correspond to key features: I
> cannot figure out a good reason for *not* having these drawers in the
> configuration.

As a customized variable org-drawers can have any content the user
choses, including none.  Before your change, the documentation said that
drawers can be _defined_ (not added) on a per-file-basis.  Past your
change, documentation now says that drawers can be _added_ on a per-file
basis (minor nit: org-drawers is no longer the corresponding variable to
a file-local setting, but the basis onto which the file-local-setting is
appended).  Existing documents will still define _all_ drawers, not just
the additional ones, however it seems you add them without checking if
they are already present (I'd think add-to-list would be better than
append).

Now, there might be a good reason to have system drawers that the user
can't change easily, but then they should not be defined in org-drawers,
perhaps?


Regards,
Achim.

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien <bzg@altern.org> writes:
>> This is quite a hypothetical case: the default value for `org-drawers'
>> contains drawers that are hardcoded and correspond to key features: I
>> cannot figure out a good reason for *not* having these drawers in the
>> configuration.
>
> As a customized variable org-drawers can have any content the user
> choses, including none.  Before your change, the documentation said that
> drawers can be _defined_ (not added) on a per-file-basis.  Past your
> change, documentation now says that drawers can be _added_ on a per-file
> basis (minor nit: org-drawers is no longer the corresponding variable to
> a file-local setting, but the basis onto which the file-local-setting is
> appended).  

Yes, you're right, and you put it very well.  If there is anything 
that you can suggest to enhance the documentation here, please do.

`org-drawers' contains the default drawers for all files, and #+DRAWERS
lets the user add new drawers on top of these default drawers.

E.g. if a user have a "HIDE" drawer that he wants to use in any Org
buffer, it's a good idea to put it in `org-drawers'.  If there is a
buffer-local drawer he want just for one file, it's a good idea to 
add it using #+DRAWERS.

> Existing documents will still define _all_ drawers, not just
> the additional ones, however it seems you add them without checking if
> they are already present (I'd think add-to-list would be better than
> append).

Fixed, thanks.

> Now, there might be a good reason to have system drawers that the user
> can't change easily, but then they should not be defined in org-drawers,
> perhaps?

I suggest this:

(defconst org-persistent-drawers '(...))
(defcustom org-custom-drawers '(...))

Then local value of org-drawers would be computed by combining the two
(with duplicates deletion.)

Would that be consistent to you?

Bastien <bzg@altern.org> writes:
> I suggest this:
>
> (defconst org-persistent-drawers '(...))
> (defcustom org-custom-drawers '(...))

"Persistent" doesn't sound right to me, but "system" is also ringing a
bit hollow.  Maybe one of the native english speakers has a better idea
of what name would be a more appropriate antonym to "custom"?

> Then local value of org-drawers would be computed by combining the two
> (with duplicates deletion.)
>
> Would that be consistent to you?

I'd say we might even have three groups of drawers already: first, the
ones used for core org functionality; they shouldn't be customizable at
all.  Next, drawers that are used for optional functionality in org —
these should be customized together with configuring the functionality
they're used with.  Last, entirely user-defined drawers that have no
special meaning within org.  It's probably too late to have a separate
name space for the "org-defined" drawers so that they won't clash with
names that a user comes up...

As an example of the second type, if a user globally configures to log
into TIMESHEET, then it would be prudent to configure TIMESHEET as a
drawer instead of LOGBOOK.  Likewise for local (re-)configuration of
log-/clock-into-drawer.  There may be more places where behaviour like
that would need to be implemented.


Regards,
Achim.

Hello,

Bastien <bzg@altern.org> writes:

> I suggest this:
>
> (defconst org-persistent-drawers '(...))
> (defcustom org-custom-drawers '(...))
>
> Then local value of org-drawers would be computed by combining the two
> (with duplicates deletion.)

In another thread (http://article.gmane.org/gmane.emacs.orgmode/51651),
I wrote a draft about a possible classification of drawers (and their
relative export defaults).

I think we may apply this classification here, with and hard-coded
properties drawer, special drawers (like logbook) and regular drawers.

Variables would become (defconst org-special-drawers '(...)) (defcustom
org-custom-drawers '(...)). Then, `org-drawers' would combine
"PROPERTIES" and the previous values.

What do you think about it (and on the mentioned draft)?


Regards,