Re: [O] [RFC] Change property drawer syntax

2014-12-06 Thread Nicolas Goaziou
Puneeth Chaganti puncha...@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,



Re: [O] [RFC] Change property drawer syntax

2014-12-05 Thread 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: [O] [RFC] Change property drawer syntax

2014-12-05 Thread Nicolas Goaziou
Hello,

Puneeth Chaganti puncha...@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: [O] [RFC] Change property drawer syntax

2014-12-05 Thread Puneeth Chaganti
On Sat, Dec 6, 2014 at 5:01 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:
 Hello,

 Puneeth Chaganti puncha...@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.


sparse-tree-ecm.org
Description: Binary data


Re: [O] [RFC] Change property drawer syntax

2014-11-28 Thread Nicolas Goaziou


Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [RFC] Change property drawer syntax

2014-11-27 Thread 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: [O] [RFC] Change property drawer syntax

2014-11-26 Thread 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: [O] [RFC] Change property drawer syntax

2014-11-26 Thread 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: [O] [RFC] Change property drawer syntax

2014-11-26 Thread Nicolas Goaziou


Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [RFC] Change property drawer syntax

2014-11-14 Thread Nicolas Goaziou


Hello,

Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [RFC] Change property drawer syntax

2014-11-14 Thread 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: X Xx
#+AUTHOR: Xxx Xxx
#+EMAIL: x...@x.xxx
#+LANGUAGE: xx

#+FILETAGS: ::x:

* Xx

** Xxxx  Xxx xxx xxx xxx - Xx xx xx xxx 

   2014-10-09 Thu 10:00

Xxx: Xxxx xx Xx (Xx XX).

* X

** CANX Xxxx  xxx xx xxx ( Xx Xx Xxx)
   DEADLINE: 2014-10-08 Wed
   :LOGBOOK:
   - X -     [2014-10-09 Thu 18:18]
   :END:
   [2014-09-30 Tue 11:18]

#+BEGIN_VERSE
Xx x xx  x xxx xx. Xxxx  x xxx:

- Xxxx x   xx  xx
- Xx x xxx
- X x xxx 

Xx xx , xx :

x Xx xxx xx xxx (xxx xx  )
x Xxxx xxx xx xxx (xxx x xx x? ?…)
x Xxxx xxx xx   'x   xx xx xxx?
x Xx x  xx xxx

X xxx   xx (x) xxx (x)?
#+END_VERSE

Xxxx [[http://orgmode.org][X  Xx Xx Xxx: {xxx} Xxx: Xxxx x 
 xxx]]
--8---cut here---end---8---

becomes:

--8---cut here---start-8---
#+TITLE: X Xx
#+AUTHOR: Xxx Xxx
#+EMAIL: x...@x.xxx
#+LANGUAGE: xx

#+FILETAGS: ::x:

* Xx

** Xxxx  Xxx xxx xxx xxx - Xx xx xx xxx 

   2014-10-09 Thu 10:00

Xxx: Xxxx xx Xx (Xx XX).

* X

ANX Xxxx  xxx xx xxx ( Xx Xx Xxx)
   DEADLINE: 2014-10-08 Wed



** C
   :LOGBOOK:
   - X -     [2014-10-09 Thu 18:18]
   :END:
   [2014-09-30 Tue 11:18]

#+BEGIN_VERSE
Xx x xx  x xxx xx. Xxxx  x xxx:

- Xxxx x   xx  xx
- Xx x xxx
- X x xxx 

Xx xx , xx :

x Xx xxx xx xxx (xxx xx  )
x Xxxx xxx xx xxx (xxx x xx x? ?…)
x Xxxx xxx xx   'x   xx xx xxx?
x Xx x  xx xxx

X xxx   xx (x) xxx (x)?
#+END_VERSE

Xxxx [[http://orgmode.org][X  Xx Xx Xxx: {xxx} Xxx: Xxxx x 
 xxx]]
--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: [O] [RFC] Change property drawer syntax

2014-11-13 Thread Nicolas Goaziou


Hello,

Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [RFC] Change property drawer syntax

2014-11-12 Thread 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: [O] [RFC] Change property drawer syntax

2014-11-12 Thread 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: [O] [RFC] Change property drawer syntax

2014-11-12 Thread 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: [O] [RFC] Change property drawer syntax

2014-11-10 Thread 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: [O] [RFC] Change property drawer syntax

2014-11-10 Thread Nicolas Goaziou


Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [RFC] Change property drawer syntax

2014-11-10 Thread 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: [O] [RFC] Change property drawer syntax

2014-11-10 Thread Nicolas Goaziou


Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [RFC] Change property drawer syntax

2014-11-10 Thread 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: [O] [RFC] Change property drawer syntax

2014-11-08 Thread Nicolas Goaziou


Hello,

Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] [RFC] Change property drawer syntax

2014-11-06 Thread Sebastien Vauban
Nicolas Goaziou wrote:
 Nicolas Goaziou m...@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.

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: [O] [RFC] Change property drawer syntax

2014-11-03 Thread Christian Egli
John Hendy jw.he...@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: [O] [RFC] Change property drawer syntax

2014-11-03 Thread Nicolas Goaziou
Hello,

Christian Egli christian.e...@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: [O] [RFC] Change property drawer syntax

2014-11-03 Thread Christian Egli
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Christian Egli christian.e...@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: [O] [RFC] Change property drawer syntax

2014-11-03 Thread Nicolas Goaziou
Christian Egli christian.e...@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: [O] [RFC] Change property drawer syntax

2014-11-01 Thread Nicolas Goaziou
Hello,

Christian Egli christian.e...@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: [O] [RFC] Change property drawer syntax

2014-10-31 Thread Christian Egli
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Nicolas Goaziou m...@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: [O] [RFC] Change property drawer syntax

2014-10-31 Thread John Hendy
On Fri, Oct 31, 2014 at 8:10 AM, Christian Egli christian.e...@sbs.ch wrote:
 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Nicolas Goaziou m...@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: [O] [RFC] Change property drawer syntax

2014-10-28 Thread Nicolas Goaziou
Nicolas Goaziou m...@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: [O] [RFC] Change property drawer syntax

2014-10-26 Thread Nicolas Goaziou
Nicolas Goaziou m...@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: [O] [RFC] Change property drawer syntax

2014-10-20 Thread Rasmus
Nicolas Goaziou m...@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: [O] [RFC] Change property drawer syntax

2014-10-15 Thread Rainer M Krug
Nicolas Goaziou m...@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: Raineratkrugsdotde
PGP: 0x0F52F982


pgpKf8kM_FDLO.pgp
Description: PGP signature


Re: [O] [RFC] Change property drawer syntax

2014-10-15 Thread Nicolas Goaziou
Hello,

Eric Abrahamsen e...@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: [O] [RFC] Change property drawer syntax

2014-10-15 Thread Nicolas Goaziou
Hello,

Rainer M Krug rai...@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: [O] [RFC] Change property drawer syntax

2014-10-15 Thread Eric Abrahamsen
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Eric Abrahamsen e...@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: [O] [RFC] Change property drawer syntax

2014-10-15 Thread Rainer M Krug
Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 Rainer M Krug rai...@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: Raineratkrugsdotde
PGP: 0x0F52F982


pgpPWf8r6ERdD.pgp
Description: PGP signature


Re: [O] [RFC] Change property drawer syntax

2014-10-15 Thread 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: [O] [RFC] Change property drawer syntax

2014-10-15 Thread Nicolas Goaziou
Hello,

Michael Brand michael.ch.br...@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
xx 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
xx [2013-08-11 Sun -2d]
xx 2014-12-21 Sun -2d
xx 2015-02-05 Thu
xx 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



[O] [RFC] Change property drawer syntax

2014-10-14 Thread 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 Goaziou0x80A93738



Re: [O] [RFC] Change property drawer syntax

2014-10-14 Thread 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 m...@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: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Nicolas Goaziou
Hello,

Andreas Leha andreas.l...@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: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Eric Abrahamsen
Nicolas Goaziou m...@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: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Michael Brand
Hi Nicolas

On Tue, Oct 14, 2014 at 4:42 PM, Nicolas Goaziou m...@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: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Nicolas Goaziou
Hello,

Eric Abrahamsen e...@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: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Nicolas Goaziou
Hello,

Michael Brand michael.ch.br...@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: [O] [RFC] Change property drawer syntax

2014-10-14 Thread Eric Abrahamsen
Nicolas Goaziou m...@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