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

[Bastien]

Achim Gratz <address@hidden> writes:

> Bastien <address@hidden> 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