Possible bug in org-cycle with property drawer

Possible bug in org-cycle with property drawer

[Nick Dokos]

I start emacs with a minimal .emacs and an empty org file, insert
a headline and insert a property drawer with org-insert-property-drawer.

The drawer starts out folded and TAB does not unfold it. I fold the headline
and unfold it: the property drawer is now unfolded and TAB does *not* fold it.
In addition, the fontification of :PROPERTIES: is wrong: there is no face
specified when I check with C-u C-x =, whereas if I add another drawer
its "front" has an org-special-keyword face. Other drawers behave normally.

IIRC, I had this problem last night, before the recent drawer changes went in,
but I didn't try it with a minimal .emacs then.

I single-stepped through org-cycle and did not find a place where the property
drawer is dealt with: is it supposed to be lumped together with other drawers?
If so, it does not seem to work.

I did not try any other "special" drawers (LOGBOOK, CLOCK, RESULTS).

Can somebody test and confirm/deny?

Thanks,
Nick

Org-mode version 7.8.03 (release_7.8.03.238.g96cd)
    (NB: includes a few unrelated local patches)
GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-01-24

Re: Possible bug in org-cycle with property drawer

[Carsten Dominik]

Do you have a newline after the :END: line?

- Carsten

On 25.1.2012, at 15:48, Nick Dokos wrote:

> I start emacs with a minimal .emacs and an empty org file, insert
> a headline and insert a property drawer with org-insert-property-drawer.
> 
> The drawer starts out folded and TAB does not unfold it. I fold the headline
> and unfold it: the property drawer is now unfolded and TAB does *not* fold it.
> In addition, the fontification of :PROPERTIES: is wrong: there is no face
> specified when I check with C-u C-x =, whereas if I add another drawer
> its "front" has an org-special-keyword face. Other drawers behave normally.
> 
> IIRC, I had this problem last night, before the recent drawer changes went in,
> but I didn't try it with a minimal .emacs then.
> 
> I single-stepped through org-cycle and did not find a place where the property
> drawer is dealt with: is it supposed to be lumped together with other drawers?
> If so, it does not seem to work.
> 
> I did not try any other "special" drawers (LOGBOOK, CLOCK, RESULTS).
> 
> Can somebody test and confirm/deny?
> 
> Thanks,
> Nick
> 
> Org-mode version 7.8.03 (release_7.8.03.238.g96cd)
>    (NB: includes a few unrelated local patches)
> GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-01-24
> 

Re: Possible bug in org-cycle with property drawer

[Nick Dokos]

Carsten Dominik <carsten.dominik@gmail.com> wrote:

> Do you have a newline after the :END: line?
> 

I did, but I tried it both with and without and it does not
seem to make any difference.

Thanks,
Nick

> 
> On 25.1.2012, at 15:48, Nick Dokos wrote:
> 
> > I start emacs with a minimal .emacs and an empty org file, insert
> > a headline and insert a property drawer with org-insert-property-drawer.
> > 
> > The drawer starts out folded and TAB does not unfold it. I fold the headline
> > and unfold it: the property drawer is now unfolded and TAB does *not* fold it.
> > In addition, the fontification of :PROPERTIES: is wrong: there is no face
> > specified when I check with C-u C-x =, whereas if I add another drawer
> > its "front" has an org-special-keyword face. Other drawers behave normally.
> > 
> > IIRC, I had this problem last night, before the recent drawer changes went in,
> > but I didn't try it with a minimal .emacs then.
> > 
> > I single-stepped through org-cycle and did not find a place where the property
> > drawer is dealt with: is it supposed to be lumped together with other drawers?
> > If so, it does not seem to work.
> > 
> > I did not try any other "special" drawers (LOGBOOK, CLOCK, RESULTS).
> > 
> > Can somebody test and confirm/deny?
> > 
> > Thanks,
> > Nick
> > 
> > Org-mode version 7.8.03 (release_7.8.03.238.g96cd)
> >    (NB: includes a few unrelated local patches)
> > GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-01-24
> > 
> 

Re: Possible bug in org-cycle with property drawer

[Bastien]

Hi Nick,

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

> I start emacs with a minimal .emacs and an empty org file, insert
> a headline and insert a property drawer with org-insert-property-drawer.
>
> The drawer starts out folded and TAB does not unfold it. I fold the headline
> and unfold it: the property drawer is now unfolded and TAB does *not* fold it.
> In addition, the fontification of :PROPERTIES: is wrong: there is no face
> specified when I check with C-u C-x =, whereas if I add another drawer
> its "front" has an org-special-keyword face. Other drawers behave
> normally.

What is the value of `org-drawers' in your file/setup?

-- 
 Bastien

Re: Possible bug in org-cycle with property drawer

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Hi Nick,
> 
> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > I start emacs with a minimal .emacs and an empty org file, insert
> > a headline and insert a property drawer with org-insert-property-drawer.
> >
> > The drawer starts out folded and TAB does not unfold it. I fold the headline
> > and unfold it: the property drawer is now unfolded and TAB does *not* fold it.
> > In addition, the fontification of :PROPERTIES: is wrong: there is no face
> > specified when I check with C-u C-x =, whereas if I add another drawer
> > its "front" has an org-special-keyword face. Other drawers behave
> > normally.
> 
> What is the value of `org-drawers' in your file/setup?
> 

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.

Thanks,
Nick

Re: Possible bug in org-cycle with property drawer

[Bastien]

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

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!


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Let-DRAWERS-append-new-drawers-to-org-drawers-instea.patch --]
[-- Type: text/x-patch, Size: 2398 bytes --]

From 00d19d068708bda1b3a647c06d457936a12ed20d Mon Sep 17 00:00:00 2001
From: Bastien Guerry <bzg@altern.org>
Date: Thu, 26 Jan 2012 09:42:04 +0100
Subject: [PATCH] Let #+DRAWERS append new drawers to `org-drawers', instead
 of replacing them.

* org.el (org-set-regexps-and-options): Set the value of
`org-drawers' by adding the value of the infile #+DRAWERS
option to that of the existing `org-drawers'.

* org.texi (Drawers): Clearly states that #+DRAWERS will add
drawers to the one originally listed in `org-drawers'.
---
 doc/org.texi |    8 ++++----
 lisp/org.el  |    2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index a285cca..d374dfb 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -1773,8 +1773,8 @@ numerically, alphabetically, by time, or by custom function.
 Sometimes you want to keep information associated with an entry, but you
 normally don't want to see it.  For this, Org mode has @emph{drawers}.
 Drawers need to be configured with the variable
-@code{org-drawers}@footnote{You can define drawers on a per-file basis
-with a line like @code{#+DRAWERS: HIDDEN PROPERTIES STATE}}.  Drawers
+@code{org-drawers}@footnote{You can define additional drawers on a 
+per-file basis with a line like @code{#+DRAWERS: HIDDEN STATE}}.  Drawers
 look like this:
 
 @example
@@ -14433,8 +14433,8 @@ Set tags that can be inherited by any entry in the file, including the
 top-level entries.
 @item #+DRAWERS: NAME1 .....
 @vindex org-drawers
-Set the file-local set of drawers.  The corresponding global variable is
-@code{org-drawers}.
+Set the file-local set of additional drawers.  The corresponding global 
+variable is @code{org-drawers}.
 @item #+LINK:  linkword replace
 @vindex org-link-abbrev-alist
 These lines (several are allowed) specify link abbreviations.
diff --git a/lisp/org.el b/lisp/org.el
index 7a68b73..5bc9aeb 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4547,7 +4547,7 @@ but the stars and the body are.")
 			      (mapcar (lambda (x) (org-split-string x ":"))
 				      (org-split-string value)))))))
 	     ((equal key "DRAWERS")
-	      (setq drawers (org-split-string value splitre)))
+	      (setq drawers (append org-drawers (org-split-string value splitre))))
 	     ((equal key "CONSTANTS")
 	      (setq const (append const (org-split-string value splitre))))
 	     ((equal key "STARTUP")
-- 
1.7.8.4


[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


-- 
 Bastien

Re: Possible bug in org-cycle with property drawer

[Nick Dokos]

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

Re: Possible bug in org-cycle with property drawer

[Achim Gratz]

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.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Possible bug in org-cycle with property drawer

[Bastien]

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

Re: Possible bug in org-cycle with property drawer

[Achim Gratz]

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.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Possible bug in org-cycle with property drawer

[Bastien]

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

Re: Possible bug in org-cycle with property drawer

[Achim Gratz]

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.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Possible bug in org-cycle with property drawer

[Nicolas Goaziou]

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,

-- 
Nicolas Goaziou

Re: Possible bug in org-cycle with property drawer

[Bastien]

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

> I start emacs with a minimal .emacs and an empty org file, insert
> a headline and insert a property drawer with
> org-insert-property-drawer.

Note that a similar problem can occur with `org-insert-drawer' if 
the inserted drawer is not known as such in the current buffer.

The solution I'm inclined to implement is to ask the user if she 
wants any unknown drawer to be added to `org-drawers'.

What do you think?

-- 
 Bastien

Re: Possible bug in org-cycle with property drawer

[Eric S Fraga]

Bastien <bzg@altern.org> writes:

> Nick Dokos <nicholas.dokos@hp.com> writes:
>
>> I start emacs with a minimal .emacs and an empty org file, insert
>> a headline and insert a property drawer with
>> org-insert-property-drawer.
>
> Note that a similar problem can occur with `org-insert-drawer' if 
> the inserted drawer is not known as such in the current buffer.
>
> The solution I'm inclined to implement is to ask the user if she 
> wants any unknown drawer to be added to `org-drawers'.
>
> What do you think?

Yes, I think this would be a good idea.

I had the same behaviour that Nick reported and I did not understand the
cause of this behaviour as I had no DRAWERS option anywhere in my file!
Of course, I didn't necessarily read any documentation <blush>.

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.8.03 (release_7.8.03.237.g674bb)