[feature request] A new cookie type [!] showing the last note taken

[feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

Over the years of using Org I often have a need to add a short note
about how to proceed with some task:

***** REVIEW check again, subscribe | sindresorhus/awesome: 😎 Awesome lists about all kinds of interesting topics :BOOKMARK:
:PROPERTIES:
:CREATED: [2020-03-15 Sun 18:59]
:Source: https://github.com/sindresorhus/awesome
:END:
:LOGBOOK:
CLOCK: [2020-03-17 Tue 16:18]--[2020-03-17 Tue 17:46] =>  1:28
CLOCK: [2020-03-17 Tue 16:03]--[2020-03-17 Tue 16:18] =>  0:15
- Refiled on [2020-03-16 Mon 23:59]
:END:

In the above example, the short note is "check again, subscribe".
The note is not fixed, but changes as I progress with completing the
task.

This is even more useful for delegated or HOLD tasks where I often need
to add a short note why the task is delegated or put on hold:

** HOLD Finish the text prop org-mode | make babel support org file links in header args (:file or :dir) [[id:468e0645-68aa-4e14-86de-e5ce153538e3][[2017-09-22 Fri] CuNbARBshearstrength]] :HOLD:
:PROPERTIES:
:CREATED: [2020-07-20 Mon 16:53]
:SHOWFROMDATE: 2020-08-15
:END:
:LOGBOOK:
- State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
  Finish the text prop org-mode
- Refiled on [2020-07-20 Mon 17:15]
CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
:END:

Seeing this note directly in the headline without a need to dig into the
task body / LOGBOOK drawer is really handy.

In this last example, I had to duplicate the note taken using built-in
note mechanism into headline, which was inconvenient. It would be handy
if I could simply add a [!] cookie (similar to [/] or [%] cookies) to
the headline to show the last note taken for this task. Then, I could
easily see the reason why the task is blocked or what I am supposed to
do with the task right in agenda view or in the folded headline.
Something like the following

** HOLD [!] make babel support org... :HOLD:
:LOGBOOK:
- State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
  Finish the text prop org-mode
- Refiled on [2020-07-20 Mon 17:15]
CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
:END:

The cookie would be replaced by the last note text, according to
user-defined format (say, "[%s] |"):

** HOLD [Finish the text prop org-mode] | make babel support org... :HOLD:
:LOGBOOK:
- State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
  Finish the text prop org-mode
- Refiled on [2020-07-20 Mon 17:15]
CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
:END:

What do you think?

Best,
Ihor

Re: [feature request] A new cookie type [!] showing the last note taken

[Nicolas Goaziou]

Hello,

Ihor Radchenko <yantar92@gmail.com> writes:

> Over the years of using Org I often have a need to add a short note
> about how to proceed with some task:
>
> ***** REVIEW check again, subscribe | sindresorhus/awesome: 😎 Awesome lists about all kinds of interesting topics :BOOKMARK:
> :PROPERTIES:
> :CREATED: [2020-03-15 Sun 18:59]
> :Source: https://github.com/sindresorhus/awesome
> :END:
> :LOGBOOK:
> CLOCK: [2020-03-17 Tue 16:18]--[2020-03-17 Tue 17:46] =>  1:28
> CLOCK: [2020-03-17 Tue 16:03]--[2020-03-17 Tue 16:18] =>  0:15
> - Refiled on [2020-03-16 Mon 23:59]
> :END:
>
> In the above example, the short note is "check again, subscribe".
> The note is not fixed, but changes as I progress with completing the
> task.
>
> This is even more useful for delegated or HOLD tasks where I often need
> to add a short note why the task is delegated or put on hold:
>
> ** HOLD Finish the text prop org-mode | make babel support org file
> links in header args (:file or :dir)
> [[id:468e0645-68aa-4e14-86de-e5ce153538e3][[2017-09-22 Fri]
> CuNbARBshearstrength]] :HOLD:
> :PROPERTIES:
> :CREATED: [2020-07-20 Mon 16:53]
> :SHOWFROMDATE: 2020-08-15
> :END:
> :LOGBOOK:
> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> Seeing this note directly in the headline without a need to dig into the
> task body / LOGBOOK drawer is really handy.
>
> In this last example, I had to duplicate the note taken using built-in
> note mechanism into headline, which was inconvenient. It would be handy
> if I could simply add a [!] cookie (similar to [/] or [%] cookies) to
> the headline to show the last note taken for this task. Then, I could
> easily see the reason why the task is blocked or what I am supposed to
> do with the task right in agenda view or in the folded headline.
> Something like the following
>
> ** HOLD [!] make babel support org... :HOLD:
> :LOGBOOK:
> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> The cookie would be replaced by the last note text, according to
> user-defined format (say, "[%s] |"):
>
> ** HOLD [Finish the text prop org-mode] | make babel support org... :HOLD:
> :LOGBOOK:
> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> What do you think?

Notes are free-form; there is no syntax describing them. Org cannot tell
what is a "note". As a consequence, pointing to "the last note taken" is
not reliable, syntax wise.

Of course, under some assumptions (e.g., notes setup is fixed, you never
write notes by hand, ...), you could guess what the last note taken is.
But again, this is not reliable, and not portable.

Regards,
-- 
Nicolas Goaziou

Re: [feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

> Notes are free-form; there is no syntax describing them. Org cannot tell
> what is a "note". As a consequence, pointing to "the last note taken" is
> not reliable, syntax wise.

> Of course, under some assumptions (e.g., notes setup is fixed, you never
> write notes by hand, ...), you could guess what the last note taken is.
> But again, this is not reliable, and not portable.

I was mainly referring to org-add-note. The last note taken with
org-add-note can be found quite reliably.

I am using the following code saving the last note into :SUMMARY:
property upon exiting the note buffer. Though it may be an overkill, not
sure how easy would it be to parse the note syntax for notes created by
org-add-note.

(defvar yant/last-note-taken ""
  "Text of the last note taken.")

(define-advice org-store-log-note (:before (&rest args) yant/org-store-last-note)
  "Store the last saved note into `yant/last-note-taken'."
  (let ((txt (buffer-string)))
    (while (string-match "\\`# .*\n[ \t\n]*" txt)
      (setq txt (replace-match "" t t txt)))
    (when (string-match "\\s-+\\'" txt)
      (setq txt (replace-match " " t t txt)))
    (when (string-match "\n" txt)
      (setq txt (replace-match " " t t txt)))
    (if (not (seq-empty-p txt))
	(setq yant/last-note-taken txt))))

(define-advice org-store-log-note (:after (&rest args) yant/org-save-last-note-into-summary-prop)
  "Save the last saved note into SUMMARY property."
  (when (and (not org-note-abort) (not (seq-empty-p yant/last-note-taken)))
    (if (eq major-mode 'org-agenda-mode)
	(org-with-point-at-org-buffer
	 (org-set-property "SUMMARY" (or yant/last-note-taken "")))
      (org-set-property "SUMMARY" (or yant/last-note-taken "")))
    (setq yant/last-note-taken nil)))

Best,
Ihor






Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> Over the years of using Org I often have a need to add a short note
>> about how to proceed with some task:
>>
>> ***** REVIEW check again, subscribe | sindresorhus/awesome: 😎 Awesome lists about all kinds of interesting topics :BOOKMARK:
>> :PROPERTIES:
>> :CREATED: [2020-03-15 Sun 18:59]
>> :Source: https://github.com/sindresorhus/awesome
>> :END:
>> :LOGBOOK:
>> CLOCK: [2020-03-17 Tue 16:18]--[2020-03-17 Tue 17:46] =>  1:28
>> CLOCK: [2020-03-17 Tue 16:03]--[2020-03-17 Tue 16:18] =>  0:15
>> - Refiled on [2020-03-16 Mon 23:59]
>> :END:
>>
>> In the above example, the short note is "check again, subscribe".
>> The note is not fixed, but changes as I progress with completing the
>> task.
>>
>> This is even more useful for delegated or HOLD tasks where I often need
>> to add a short note why the task is delegated or put on hold:
>>
>> ** HOLD Finish the text prop org-mode | make babel support org file
>> links in header args (:file or :dir)
>> [[id:468e0645-68aa-4e14-86de-e5ce153538e3][[2017-09-22 Fri]
>> CuNbARBshearstrength]] :HOLD:
>> :PROPERTIES:
>> :CREATED: [2020-07-20 Mon 16:53]
>> :SHOWFROMDATE: 2020-08-15
>> :END:
>> :LOGBOOK:
>> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>>   Finish the text prop org-mode
>> - Refiled on [2020-07-20 Mon 17:15]
>> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
>> :END:
>>
>> Seeing this note directly in the headline without a need to dig into the
>> task body / LOGBOOK drawer is really handy.
>>
>> In this last example, I had to duplicate the note taken using built-in
>> note mechanism into headline, which was inconvenient. It would be handy
>> if I could simply add a [!] cookie (similar to [/] or [%] cookies) to
>> the headline to show the last note taken for this task. Then, I could
>> easily see the reason why the task is blocked or what I am supposed to
>> do with the task right in agenda view or in the folded headline.
>> Something like the following
>>
>> ** HOLD [!] make babel support org... :HOLD:
>> :LOGBOOK:
>> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>>   Finish the text prop org-mode
>> - Refiled on [2020-07-20 Mon 17:15]
>> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
>> :END:
>>
>> The cookie would be replaced by the last note text, according to
>> user-defined format (say, "[%s] |"):
>>
>> ** HOLD [Finish the text prop org-mode] | make babel support org... :HOLD:
>> :LOGBOOK:
>> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>>   Finish the text prop org-mode
>> - Refiled on [2020-07-20 Mon 17:15]
>> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
>> :END:
>>
>> What do you think?
>
> Notes are free-form; there is no syntax describing them. Org cannot tell
> what is a "note". As a consequence, pointing to "the last note taken" is
> not reliable, syntax wise.
>
> Of course, under some assumptions (e.g., notes setup is fixed, you never
> write notes by hand, ...), you could guess what the last note taken is.
> But again, this is not reliable, and not portable.
>
> Regards,
> -- 
> Nicolas Goaziou

Re: [feature request] A new cookie type [!] showing the last note taken

[Nicolas Goaziou]

Ihor Radchenko <yantar92@gmail.com> writes:

> I was mainly referring to org-add-note. The last note taken with
> org-add-note can be found quite reliably.
>
> I am using the following code saving the last note into :SUMMARY:
> property upon exiting the note buffer. Though it may be an overkill, not
> sure how easy would it be to parse the note syntax for notes created by
> org-add-note.

You cannot reliably.

> (defvar yant/last-note-taken ""
>   "Text of the last note taken.")
>
> (define-advice org-store-log-note (:before (&rest args) yant/org-store-last-note)
>   "Store the last saved note into `yant/last-note-taken'."
>   (let ((txt (buffer-string)))
>     (while (string-match "\\`# .*\n[ \t\n]*" txt)
>       (setq txt (replace-match "" t t txt)))
>     (when (string-match "\\s-+\\'" txt)
>       (setq txt (replace-match " " t t txt)))
>     (when (string-match "\n" txt)
>       (setq txt (replace-match " " t t txt)))
>     (if (not (seq-empty-p txt))
> 	(setq yant/last-note-taken txt))))
>
> (define-advice org-store-log-note (:after (&rest args) yant/org-save-last-note-into-summary-prop)
>   "Save the last saved note into SUMMARY property."
>   (when (and (not org-note-abort) (not (seq-empty-p yant/last-note-taken)))
>     (if (eq major-mode 'org-agenda-mode)
> 	(org-with-point-at-org-buffer
> 	 (org-set-property "SUMMARY" (or yant/last-note-taken "")))
>       (org-set-property "SUMMARY" (or yant/last-note-taken "")))
>     (setq yant/last-note-taken nil)))

This implementation is only tangentially related to a "last note". You
want to introduce some syntax to display the value a given property,
here SUMMARY. But `org-add-note' is not the only way to add a note. 

Again, on a given document, you can only guess what is the "last note".
This is not reliable enough to extend the syntax.

Regards,

Re: [feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

> Again, on a given document, you can only guess what is the "last note".
> This is not reliable enough to extend the syntax.

I feel that my understand of "note" in context of org is different from
yours. Is there a formal definition of "note" in org?

If no, there is indeed no reliable way to capture "last note". However,
we can formalise the "last note taken" to "last note taken using
org-add-note".

> This implementation is only tangentially related to a "last note". You
> want to introduce some syntax to display the value a given property,
> here SUMMARY. But `org-add-note' is not the only way to add a note. 

org-add-note is the only way I am aware about (except plain text,
indeed). That's why I wrote the function saving the last note taken
using org-add-note into SUMMARY. The property is only used here for
convenient retrieval, not because I implied showing a property value.

May I know what are the other ways to add note via interactive function
in Org?

Best,
Ihor

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> I was mainly referring to org-add-note. The last note taken with
>> org-add-note can be found quite reliably.
>>
>> I am using the following code saving the last note into :SUMMARY:
>> property upon exiting the note buffer. Though it may be an overkill, not
>> sure how easy would it be to parse the note syntax for notes created by
>> org-add-note.
>
> You cannot reliably.
>
>> (defvar yant/last-note-taken ""
>>   "Text of the last note taken.")
>>
>> (define-advice org-store-log-note (:before (&rest args) yant/org-store-last-note)
>>   "Store the last saved note into `yant/last-note-taken'."
>>   (let ((txt (buffer-string)))
>>     (while (string-match "\\`# .*\n[ \t\n]*" txt)
>>       (setq txt (replace-match "" t t txt)))
>>     (when (string-match "\\s-+\\'" txt)
>>       (setq txt (replace-match " " t t txt)))
>>     (when (string-match "\n" txt)
>>       (setq txt (replace-match " " t t txt)))
>>     (if (not (seq-empty-p txt))
>> 	(setq yant/last-note-taken txt))))
>>
>> (define-advice org-store-log-note (:after (&rest args) yant/org-save-last-note-into-summary-prop)
>>   "Save the last saved note into SUMMARY property."
>>   (when (and (not org-note-abort) (not (seq-empty-p yant/last-note-taken)))
>>     (if (eq major-mode 'org-agenda-mode)
>> 	(org-with-point-at-org-buffer
>> 	 (org-set-property "SUMMARY" (or yant/last-note-taken "")))
>>       (org-set-property "SUMMARY" (or yant/last-note-taken "")))
>>     (setq yant/last-note-taken nil)))
>
> This implementation is only tangentially related to a "last note". You
> want to introduce some syntax to display the value a given property,
> here SUMMARY. But `org-add-note' is not the only way to add a note. 
>
> Again, on a given document, you can only guess what is the "last note".
> This is not reliable enough to extend the syntax.
>
> Regards,

Re: [feature request] A new cookie type [!] showing the last note taken

[Nicolas Goaziou]

Ihor Radchenko <yantar92@gmail.com> writes:

> I feel that my understand of "note" in context of org is different from
> yours. Is there a formal definition of "note" in org?

As I stated in my first post a few hours ago:

   Notes are mostly free-form; there is no syntax describing them.

> However, we can formalise the "last note taken" to "last note taken
> using org-add-note".

This is more realistic, but you are then binding the tool
(`org-add-note') to the syntax ("[!]"), which is a step in the wrong
direction. We must not assume Org mode is the only tool writing Org
documents.

> org-add-note is the only way I am aware about (except plain text,
> indeed). That's why I wrote the function saving the last note taken
> using org-add-note into SUMMARY. The property is only used here for
> convenient retrieval, not because I implied showing a property value.

I understand the property was used for convenience, but showing its
value is the only problem your can really claim solving at the moment.

> May I know what are the other ways to add note via interactive function
> in Org?

Capture is certainly one way. In fact, `org-add-note' could (should ?)
be rewritten using Capture library.

I wouldn't dismiss plain text insertion too easily, either. It also
includes external tools. What happens if an external tool automatically
insert notes?

The feature you are requesting could make sense if notes had a clear
syntax. This would bring some interesting features, too (e.g., being
able to list all notes in an entry, accurately). But it would also raise
new problems, as any syntax change (backward compatibility with old
documents, external tools...). 

Regards,

Re: [feature request] A new cookie type [!] showing the last note taken

[Eric Abrahamsen]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> I feel that my understand of "note" in context of org is different from
>> yours. Is there a formal definition of "note" in org?
>
> As I stated in my first post a few hours ago:
>
>    Notes are mostly free-form; there is no syntax describing them.
>
>> However, we can formalise the "last note taken" to "last note taken
>> using org-add-note".
>
> This is more realistic, but you are then binding the tool
> (`org-add-note') to the syntax ("[!]"), which is a step in the wrong
> direction. We must not assume Org mode is the only tool writing Org
> documents.
>
>> org-add-note is the only way I am aware about (except plain text,
>> indeed). That's why I wrote the function saving the last note taken
>> using org-add-note into SUMMARY. The property is only used here for
>> convenient retrieval, not because I implied showing a property value.
>
> I understand the property was used for convenience, but showing its
> value is the only problem your can really claim solving at the moment.
>
>> May I know what are the other ways to add note via interactive function
>> in Org?
>
> Capture is certainly one way. In fact, `org-add-note' could (should ?)
> be rewritten using Capture library.
>
> I wouldn't dismiss plain text insertion too easily, either. It also
> includes external tools. What happens if an external tool automatically
> insert notes?
>
> The feature you are requesting could make sense if notes had a clear
> syntax. This would bring some interesting features, too (e.g., being
> able to list all notes in an entry, accurately). But it would also raise
> new problems, as any syntax change (backward compatibility with old
> documents, external tools...). 

FWIW I'd be very happy to see a formalized note syntax. I make heavy use
of arbitrary notes and state-change notes -- what needs to be done NEXT,
how long has a todo been in WAIT state -- and would love to be able to
build more tools on top of that.

Re: [feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

> I wouldn't dismiss plain text insertion too easily, either. It also
> includes external tools. What happens if an external tool automatically
> insert notes?
>
> The feature you are requesting could make sense if notes had a clear
> syntax. This would bring some interesting features, too (e.g., being
> able to list all notes in an entry, accurately). But it would also raise
> new problems, as any syntax change (backward compatibility with old
> documents, external tools...). 

I would not call defining syntax for notes "a syntax change". Rather
addition to syntax. Since there was no formal definition of notes in the
past, introducing formal syntax for notes should not break any existing
tool. If anything, it should make it easier for those tools to deal with
notes.

For the compatibility, we can reuse the frequently used (at least,
because it is built-in) syntax used by `org-add-note' (see below).


> This is more realistic, but you are then binding the tool
> (`org-add-note') to the syntax ("[!]"), which is a step in the wrong
> direction. We must not assume Org mode is the only tool writing Org
> documents.

Good point.

Instead of linking to the function, we can define the format used by
`org-add-note' as a formal format for notes. Currently `org-add-note'
uses the following format:

- <note heading> \\
  <User note, possibly multi-line>

The <note heading> is taken from `org-log-note-headings'.

Notably, this syntax is partially used in org, despite lack of formal
definition. For example, `org-habit-parse-todo' assumes that state
change notes were added by `org-add-note' using format defined in
`org-log-note-headings'. All the external tools dealing with state
change statistics already have to consider this syntax.

Also, it can nicely play with the existing built-in
`org-element-plain-list-parser' with note being a special kind of list
element.

Best,
Ihor

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> I feel that my understand of "note" in context of org is different from
>> yours. Is there a formal definition of "note" in org?
>
> As I stated in my first post a few hours ago:
>
>    Notes are mostly free-form; there is no syntax describing them.
>
>> However, we can formalise the "last note taken" to "last note taken
>> using org-add-note".
>
> This is more realistic, but you are then binding the tool
> (`org-add-note') to the syntax ("[!]"), which is a step in the wrong
> direction. We must not assume Org mode is the only tool writing Org
> documents.
>
>> org-add-note is the only way I am aware about (except plain text,
>> indeed). That's why I wrote the function saving the last note taken
>> using org-add-note into SUMMARY. The property is only used here for
>> convenient retrieval, not because I implied showing a property value.
>
> I understand the property was used for convenience, but showing its
> value is the only problem your can really claim solving at the moment.
>
>> May I know what are the other ways to add note via interactive function
>> in Org?
>
> Capture is certainly one way. In fact, `org-add-note' could (should ?)
> be rewritten using Capture library.
>
> I wouldn't dismiss plain text insertion too easily, either. It also
> includes external tools. What happens if an external tool automatically
> insert notes?
>
> The feature you are requesting could make sense if notes had a clear
> syntax. This would bring some interesting features, too (e.g., being
> able to list all notes in an entry, accurately). But it would also raise
> new problems, as any syntax change (backward compatibility with old
> documents, external tools...). 
>
> Regards,

Re: [feature request] A new cookie type [!] showing the last note taken

[Julius Müller]

Am 31.08.20 um 04:26 schrieb Ihor Radchenko:
> I would not call defining syntax for notes "a syntax change". Rather
> addition to syntax. Since there was no formal definition of notes in the
> past, introducing formal syntax for notes should not break any existing
> tool. If anything, it should make it easier for those tools to deal with
> notes.

Make it easier perhaps -- once the tool has been changed to the new
syntax. But you might break current usage. And not everyone using such
tools has coding skills to make those tools work again.

Prof. Kitchin kindly gifted me with some code for a flash card learning
system. That code uses org-add-log-setup directly. Notes added like that
might not follow your newly added syntax.

Julius

Re: [feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

> Make it easier perhaps -- once the tool has been changed to the new
> syntax. But you might break current usage. And not everyone using such
> tools has coding skills to make those tools work again.

> Prof. Kitchin kindly gifted me with some code for a flash card learning
> system. That code uses org-add-log-setup directly. Notes added like that
> might not follow your newly added syntax.

Note that the syntax I proposed is not new. It is already used by
org-add-note (which is, by the way, calling org-add-log-setup ->
org-add-log-note -> org-store-log-note. org-log-note-headings is only
directly used in the last function).

I do not propose to change the old behaviour. I just propose to take the
de-facto used syntax and say "that's what org-mode calls a note". None of
the existing org-mode functions need to be changed to conform with this
formalised note syntax.

However, we can implement a new set of functionality (like what I asked
in this feature request) that will work assuming notes are created with
the newly introduced syntax. Any old notes created using alternative
syntax (which can be anything, since note syntax was never formalised)
will simply not be recognised (as they are not recognised now because of
lack of "note" definition).

If external tools defined an alternative syntax for a note, notes
created following that syntax will not be broken. Those external tools
can keep using their own syntax. The only difference is that **new**
org-mode functions supporting the new syntax will not be able to work
with third-party notes. However, these new org-mode functions will not
be possible if we keep the note syntax undefined.

Best,
Ihor


Julius Müller <Julius.S.Mueller@eureca.de> writes:

> Am 31.08.20 um 04:26 schrieb Ihor Radchenko:
>> I would not call defining syntax for notes "a syntax change". Rather
>> addition to syntax. Since there was no formal definition of notes in the
>> past, introducing formal syntax for notes should not break any existing
>> tool. If anything, it should make it easier for those tools to deal with
>> notes.
>
> Make it easier perhaps -- once the tool has been changed to the new
> syntax. But you might break current usage. And not everyone using such
> tools has coding skills to make those tools work again.
>
> Prof. Kitchin kindly gifted me with some code for a flash card learning
> system. That code uses org-add-log-setup directly. Notes added like that
> might not follow your newly added syntax.
>
> Julius

Re: [feature request] A new cookie type [!] showing the last note taken

[Nicolas Goaziou]

Hello,

Ihor Radchenko <yantar92@gmail.com> writes:

> Instead of linking to the function, we can define the format used by
> `org-add-note' as a formal format for notes. Currently `org-add-note'
> uses the following format:
>
> - <note heading> \\
>   <User note, possibly multi-line>

This is not specific enough to be considered as syntax. The risk of
false positive is too high. This is the reason why notes were never
considered as syntactically meaningful so far.

> The <note heading> is taken from `org-log-note-headings'.

This is configurable, which is not a good idea for any new syntax.

Regards,
-- 
Nicolas Goaziou

Re: [feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

>> - <note heading> \\
>>   <User note, possibly multi-line>
>
> This is not specific enough to be considered as syntax. The risk of
> false positive is too high. This is the reason why notes were never
> considered as syntactically meaningful so far.

I may miss something, but it does not look [for me] any more specific
in comparison with headline format:

- headline :: "^\*+ .+$"
- first line of note :: "^[ \t]*-.+\\\\$"

Body of the note can be extracted using existing item parser (removing
the first line).

>> The <note heading> is taken from `org-log-note-headings'.
>
> This is configurable, which is not a good idea for any new syntax.

Agree. The syntax may allow arbitrary first line instead of limiting it
to `org-log-note-headings'. Though `org-log-note-headings' can still be
used to define special types of notes - not a part of syntax, but for
org-mode functionality in Emacs.

Best,
Ihor


Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> Instead of linking to the function, we can define the format used by
>> `org-add-note' as a formal format for notes. Currently `org-add-note'
>> uses the following format:
>>
>> - <note heading> \\
>>   <User note, possibly multi-line>
>
> This is not specific enough to be considered as syntax. The risk of
> false positive is too high. This is the reason why notes were never
> considered as syntactically meaningful so far.
>
>> The <note heading> is taken from `org-log-note-headings'.
>
> This is configurable, which is not a good idea for any new syntax.
>
> Regards,
> -- 
> Nicolas Goaziou

Re: [feature request] A new cookie type [!] showing the last note taken

[Nicolas Goaziou]

Hello,

Ihor Radchenko <yantar92@gmail.com> writes:

> I may miss something, but it does not look [for me] any more specific
> in comparison with headline format:
>
> - headline :: "^\*+ .+$"
> - first line of note :: "^[ \t]*-.+\\\\$"

I do see a big difference, tho. Starting a line with an asterisk
followed by a space _always_ create a headline. However, writing an item
with a line break at the end of its first line is not necessarily
a note.

  - Question.\\
    Why would this be a note?

  - Answer.\\
    It isn't.

So, suggested syntax is too ambiguous.

Regards,
-- 
Nicolas Goaziou

Re: [feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

> However, writing an item
> with a line break at the end of its first line is not necessarily
> a note.

You are right. I missed that \\ is also a newline for LaTeX export.

Another possibility is re-purposing counter definition from ordered
lists. Currently the "\\[@[0-9]+\\]" is used to force item number in
ordered lists:

1. item
5. [@5] another item
6. next item

However, it is unused it unordered lists. We might define a note as a
unnumbered list item with [@note]:

- [@note] This is note

In addition, all the list items in :LOGBOOK: drawer may be considered
notes (to avoid a need to change the current format of the
automatically added notes).

What do you think?

Best,
Ihor

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> I may miss something, but it does not look [for me] any more specific
>> in comparison with headline format:
>>
>> - headline :: "^\*+ .+$"
>> - first line of note :: "^[ \t]*-.+\\\\$"
>
> I do see a big difference, tho. Starting a line with an asterisk
> followed by a space _always_ create a headline. However, writing an item
> with a line break at the end of its first line is not necessarily
> a note.
>
>   - Question.\\
>     Why would this be a note?
>
>   - Answer.\\
>     It isn't.
>
> So, suggested syntax is too ambiguous.
>
> Regards,
> -- 
> Nicolas Goaziou

Re: [feature request] A new cookie type [!] showing the last note taken

[Allen Li]

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

On Sat, Aug 29, 2020 at 6:42 AM Ihor Radchenko <yantar92@gmail.com> wrote:

>
> Over the years of using Org I often have a need to add a short note
> about how to proceed with some task:
>
> ***** REVIEW check again, subscribe | sindresorhus/awesome: 😎 Awesome
> lists about all kinds of interesting topics :BOOKMARK:
> :PROPERTIES:
> :CREATED: [2020-03-15 Sun 18:59]
> :Source: https://github.com/sindresorhus/awesome
> :END:
> :LOGBOOK:
> CLOCK: [2020-03-17 Tue 16:18]--[2020-03-17 Tue 17:46] =>  1:28
> CLOCK: [2020-03-17 Tue 16:03]--[2020-03-17 Tue 16:18] =>  0:15
> - Refiled on [2020-03-16 Mon 23:59]
> :END:
>
> In the above example, the short note is "check again, subscribe".
> The note is not fixed, but changes as I progress with completing the
> task.
>

Everyone has their own workflows, but I think the way you are approaching
this problem is "wrong".  Under the GTD methodology, there is the concept
of a project (some higher goal to be achieved) and next actions (the
concrete tasks to do next to achieve the project).  You would only track
the next action in your regular toto list. In Org mode, this would look
like:

* PROJECT make babel support org file links in header args (:file or :dir)
** TODO Finish the text prop org-mode

My anecdotal impression is that many people using Org do this (see
https://orgmode.org/worg/org-gtd-etc.html), so they have no need for a
"last note taken embedded in headline" feature.  As a practical matter, I
would find it inconvenient to have both the "last note take"/"next action"
and the overall project headline appear in the agenta view because it makes
the text too wide.  If I need to associate the next action with the overall
project, I take advantage of the CATEGORY property:

* PROJECT make babel support org file links in header args (:file or :dir)
:PROPERTIES:
:CATEGORY: BabelLinks
:END:
** TODO Finish the text prop org-mode

Which would show in the agenda as:

BabelLinks: TODO Finish the text prop org-mode

I have only been partially paying attention to this discussion thread, but
this sounds like both a feature with limited appeal and significant
complexity to implement, so I would suggest implementing it yourself for
your own use case, and then bringing it to the mailing list to share.  Once
you have a dozen people using it, it will likely have developed into a
mature enough form to include in Org mode.

Just my 2 cents.


> This is even more useful for delegated or HOLD tasks where I often need
> to add a short note why the task is delegated or put on hold:
>
> ** HOLD Finish the text prop org-mode | make babel support org file links
> in header args (:file or :dir)
> [[id:468e0645-68aa-4e14-86de-e5ce153538e3][[2017-09-22 Fri]
> CuNbARBshearstrength]] :HOLD:
> :PROPERTIES:
> :CREATED: [2020-07-20 Mon 16:53]
> :SHOWFROMDATE: 2020-08-15
> :END:
> :LOGBOOK:
> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> Seeing this note directly in the headline without a need to dig into the
> task body / LOGBOOK drawer is really handy.
>
> In this last example, I had to duplicate the note taken using built-in
> note mechanism into headline, which was inconvenient. It would be handy
> if I could simply add a [!] cookie (similar to [/] or [%] cookies) to
> the headline to show the last note taken for this task. Then, I could
> easily see the reason why the task is blocked or what I am supposed to
> do with the task right in agenda view or in the folded headline.
> Something like the following
>
> ** HOLD [!] make babel support org... :HOLD:
> :LOGBOOK:
> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> The cookie would be replaced by the last note text, according to
> user-defined format (say, "[%s] |"):
>
> ** HOLD [Finish the text prop org-mode] | make babel support org... :HOLD:
> :LOGBOOK:
> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> What do you think?
>
> Best,
> Ihor
>
>

[-- Attachment #2: Type: text/html, Size: 5567 bytes --]

Re: [feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

> Everyone has their own workflows, but I think the way you are approaching
> this problem is "wrong". 

I think I need to elaborate on the use-cases more then.

I am well aware about the concept of NEXT actions, GTD, projects, and
using categories to bring task context in agenda. However, the problem I
am trying to solve is more subtle.

Sometimes, subdividing a task into NEXT sub-tasks is simply overkill
leading to redundancy. Consider the following example of reading a book,
when the task of reading is also part of bigger project:

* PROJECT Combine GTD approach with Zettelkasten in org-mode
:PROPERTIES:
:CATEGORY: ZettelOrg
:END:

Zettelkasten method looks promising to combine many pieces of
information from various research papers together. However, most of
papers I read are initially captured as TODO - within framework of GTD.

The original GTD approach recommends separating reference materials and
the todo-lists. I need to explore the reasons why it is so in more
details and decide if I need to separate paper notes from their "read"
tasks and how to manage the separation if I decide to do it.

** Literature review

*** NEXT re-read Getting Things Done by David Allen

[[attachment:GTD.pdf]]

----------------------------

That's indeed a fairly big task - reading the whole book. Splitting the
task sounds reasonable:

*** NEXT re-read Getting Things Done by David Allen

[[attachment:GTD.pdf]]

**** NEXT Read Chapter 1
**** TODO Read Chapter 2
**** TODO Read Chapter 3
<...>

----------------------------

There is a problem with this approach though - individual tasks will
appear without context in agenda:

* today NEXT Read Chapter 1

As you mentioned, we can bring some context to the task simply by
showing category:

* today ZettelOrg: NEXT Read Chapter 1

You can see the problem - we already have high-level category for the
project.

Of course, we can define separate category just for the "re-read" task.
But then, we will lose the information about higher-level project. If
you look at the project description I put in the example, you can see
that the higher-level context is, in fact, important - I do not intend to
read the GTD book in generic way, but I intend to explore the possible
combination of Zettelkasten and GTD. This context is general for the
whole project and will apply to other books/articles that may appear in
the project "to-read" list.

There is also another approach to bring context to the individual "Read
Chapter" tasks - we can mention the book title in all of them:

*** NEXT re-read Getting Things Done by David Allen

[[attachment:GTD.pdf]]

**** NEXT Read Chapter 1. Getting Things Done by David Allen
**** TODO Read Chapter 2. Getting Things Done by David Allen
**** TODO Read Chapter 3. Getting Things Done by David Allen
<...>

This works fine, but it is redundant - we have to carry over the first
headline to every sub-task.

So, I suggest to add a short note to the main task instead:

*** NEXT chapter 1 | re-read Getting Things Done by David Allen

[[attachment:GTD.pdf]]

This is much shorter and does not require creating a bunch of similar
tasks. I just need to look at the main task in the morning and decide
what I am going to do with it that day (like read first chapter).

One can argue that the fact that I want to read a chapter of the book is
so trivial that there is no need to bother writing it down. However, it
actually helps tremendously. Look at the following two tasks:

* today NEXT re-read Getting Things Done by David Allen
* today NEXT chapter 1 | re-read Getting Things Done by David Allen

According to my experience using GTD + agenda, I tend to feel a little
depressed by looking at the first task - "OMG, I need to read the whole
book! Better go ahead and clock-in an easier task - I can finish it
quickly." Thinking that I can just read a single chapter is not
something coming to my mind immediately - I need extra effort to realise
it. And things become worse when we have a task, which is less trivial
than reading a book (but also requires simple repetitive [but less
obvious] actions). 

Finally, note that I have an attachment link to the book in the task
description: 

*** NEXT re-read Getting Things Done by David Allen

[[attachment:GTD.pdf]]

This is handy, because I can open this link directly from agenda view
via C-c C-o. If I had to create individual tasks for each chapter, I
would need to carry over the link as well - another bit of redundancy.

> Under the GTD methodology, there is the concept
> of a project (some higher goal to be achieved) and next actions (the
> concrete tasks to do next to achieve the project).  You would only track
> the next action in your regular toto list. In Org mode, this would look
> like:
>
> * PROJECT make babel support org file links in header args (:file or :dir)
> ** TODO Finish the text prop org-mode
>
> My anecdotal impression is that many people using Org do this (see
> https://orgmode.org/worg/org-gtd-etc.html), so they have no need for a
> "last note taken embedded in headline" feature.  As a practical matter, I
> would find it inconvenient to have both the "last note take"/"next action"
> and the overall project headline appear in the agenta view because it makes
> the text too wide.  If I need to associate the next action with the overall
> project, I take advantage of the CATEGORY property:
>
> * PROJECT make babel support org file links in header args (:file or :dir)
> :PROPERTIES:
> :CATEGORY: BabelLinks
> :END:
> ** TODO Finish the text prop org-mode
>
> Which would show in the agenda as:
>
> BabelLinks: TODO Finish the text prop org-mode

I hope that the above example gave enough context on why splitting a
task into sub-tasks is not always a good idea, even if you follow GTD.

However, what I described does not strictly require the functionality I
am requesting in this thread - we can as well directly modify the
headline.

Another situation when showing task-local context can be handy is when
the task is blocked by something (I am talking about concept of WAIT
tasks in GTD). In my example below, HOLD refers to task that I plan to
do as soon as it is not blocked by something else - equivalent of WAIT
tasks in GTD:

** HOLD Finish the text prop org-mode | make babel support org file links

In this example, note "Finish the text prop org-mode" refers to another
project, which I would like to focus on before starting the task.
Working on that org file links is "on hold" for now.

Seeing why the task is "on hold" is extremely useful when I do my weekly
review (as recommended by GTD). I can look at it and decide if the
reason the task is "on hold" is still valid or I can go ahead and mark
it NEXT.

One may argue that my example can be covered by task dependencies (via
org-edna). However, that is too restrictive in general case. Even though
initial reason why I put a task "on hold" is other higher-priority task,
I may, for example, be on vacation another week and thus have a time to
work on both tasks simultaneously instead of a need to focus on one
thing only. So, seeing the reason of putting "on hold" during weekly
review is important for me.

---------------

I hope the above examples explain why I suggested to implement the
new cookie type - it can be used in both the described situations.

> I have only been partially paying attention to this discussion thread, but
> this sounds like both a feature with limited appeal and significant
> complexity to implement, so I would suggest implementing it yourself for
> your own use case, and then bringing it to the mailing list to share.  Once
> you have a dozen people using it, it will likely have developed into a
> mature enough form to include in Org mode.

I actually have working code showing the last note in agenda view. As I
described, I believe that such functionality can be useful. However, my
own implementation is limited to agenda (because I mostly use agenda).
If one prefers to browse org buffers directly, they will miss the
feature. Headline cookies should be more universal and also allow to
show the last note selectively, only in the headlines containing the
cookie.

The complexity only comes from the fact that we don't have formal
definition of "note".

> As a practical matter, I
> would find it inconvenient to have both the "last note take"/"next action"
> and the overall project headline appear in the agenta view because it makes
> the text too wide.

That's one of the reasons I propose to implement it as a cookie type.
You do not have to put [!] in your headline if do not want to.

Best,
Ihor


Allen Li <darkfeline@felesatra.moe> writes:

> On Sat, Aug 29, 2020 at 6:42 AM Ihor Radchenko <yantar92@gmail.com> wrote:
>
>>
>> Over the years of using Org I often have a need to add a short note
>> about how to proceed with some task:
>>
>> ***** REVIEW check again, subscribe | sindresorhus/awesome: 😎 Awesome
>> lists about all kinds of interesting topics :BOOKMARK:
>> :PROPERTIES:
>> :CREATED: [2020-03-15 Sun 18:59]
>> :Source: https://github.com/sindresorhus/awesome
>> :END:
>> :LOGBOOK:
>> CLOCK: [2020-03-17 Tue 16:18]--[2020-03-17 Tue 17:46] =>  1:28
>> CLOCK: [2020-03-17 Tue 16:03]--[2020-03-17 Tue 16:18] =>  0:15
>> - Refiled on [2020-03-16 Mon 23:59]
>> :END:
>>
>> In the above example, the short note is "check again, subscribe".
>> The note is not fixed, but changes as I progress with completing the
>> task.
>>
>
> Everyone has their own workflows, but I think the way you are approaching
> this problem is "wrong".  Under the GTD methodology, there is the concept
> of a project (some higher goal to be achieved) and next actions (the
> concrete tasks to do next to achieve the project).  You would only track
> the next action in your regular toto list. In Org mode, this would look
> like:
>
> * PROJECT make babel support org file links in header args (:file or :dir)
> ** TODO Finish the text prop org-mode
>
> My anecdotal impression is that many people using Org do this (see
> https://orgmode.org/worg/org-gtd-etc.html), so they have no need for a
> "last note taken embedded in headline" feature.  As a practical matter, I
> would find it inconvenient to have both the "last note take"/"next action"
> and the overall project headline appear in the agenta view because it makes
> the text too wide.  If I need to associate the next action with the overall
> project, I take advantage of the CATEGORY property:
>
> * PROJECT make babel support org file links in header args (:file or :dir)
> :PROPERTIES:
> :CATEGORY: BabelLinks
> :END:
> ** TODO Finish the text prop org-mode
>
> Which would show in the agenda as:
>
> BabelLinks: TODO Finish the text prop org-mode
>
> I have only been partially paying attention to this discussion thread, but
> this sounds like both a feature with limited appeal and significant
> complexity to implement, so I would suggest implementing it yourself for
> your own use case, and then bringing it to the mailing list to share.  Once
> you have a dozen people using it, it will likely have developed into a
> mature enough form to include in Org mode.
>
> Just my 2 cents.
>
>
>> This is even more useful for delegated or HOLD tasks where I often need
>> to add a short note why the task is delegated or put on hold:
>>
>> ** HOLD Finish the text prop org-mode | make babel support org file links
>> in header args (:file or :dir)
>> [[id:468e0645-68aa-4e14-86de-e5ce153538e3][[2017-09-22 Fri]
>> CuNbARBshearstrength]] :HOLD:
>> :PROPERTIES:
>> :CREATED: [2020-07-20 Mon 16:53]
>> :SHOWFROMDATE: 2020-08-15
>> :END:
>> :LOGBOOK:
>> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>>   Finish the text prop org-mode
>> - Refiled on [2020-07-20 Mon 17:15]
>> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
>> :END:
>>
>> Seeing this note directly in the headline without a need to dig into the
>> task body / LOGBOOK drawer is really handy.
>>
>> In this last example, I had to duplicate the note taken using built-in
>> note mechanism into headline, which was inconvenient. It would be handy
>> if I could simply add a [!] cookie (similar to [/] or [%] cookies) to
>> the headline to show the last note taken for this task. Then, I could
>> easily see the reason why the task is blocked or what I am supposed to
>> do with the task right in agenda view or in the folded headline.
>> Something like the following
>>
>> ** HOLD [!] make babel support org... :HOLD:
>> :LOGBOOK:
>> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>>   Finish the text prop org-mode
>> - Refiled on [2020-07-20 Mon 17:15]
>> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
>> :END:
>>
>> The cookie would be replaced by the last note text, according to
>> user-defined format (say, "[%s] |"):
>>
>> ** HOLD [Finish the text prop org-mode] | make babel support org... :HOLD:
>> :LOGBOOK:
>> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>>   Finish the text prop org-mode
>> - Refiled on [2020-07-20 Mon 17:15]
>> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
>> :END:
>>
>> What do you think?
>>
>> Best,
>> Ihor
>>
>>

Re: [feature request] A new cookie type [!] showing the last note taken

[Eric Abrahamsen]

Ihor Radchenko <yantar92@gmail.com> writes:

>> Everyone has their own workflows, but I think the way you are approaching
>> this problem is "wrong". 
>
> I think I need to elaborate on the use-cases more then.
>
> I am well aware about the concept of NEXT actions, GTD, projects, and
> using categories to bring task context in agenda. However, the problem I
> am trying to solve is more subtle.
>
> Sometimes, subdividing a task into NEXT sub-tasks is simply overkill
> leading to redundancy. Consider the following example of reading a book,
> when the task of reading is also part of bigger project:

Chiming in briefly to say that I agree: many of my TODO use-cases simply
don't make any sense broken up into sub-tasks. So much of what I do is
email-based discussions -- about project proposals, textual edits,
contract negotiations -- and as the discussion evolves the TODO bounces
back and forth between NEXT and WAIT. This is also the fundamental
approach of Gnorb. There's no useful way to break that evolving
discussion into subtasks. All I want to know is, what am I WAITing on
and how long have I been WAITing, and if the ball's in my court, what am
I doing NEXT.

I looked into implementing something like what Ihor is suggesting
(except using a message-area echo), ran into some of the same
difficulties (the semi-real status of notes), and then noticed that
<SPC> on an Agenda item shows the item in another window with its
LOGBOOK expanded, meaning you can see the whole evolution of the TODO at
a glance. And "o" hides it away again. That took most of the steam out
of my plans, and I figured it was good enough.

Re the formatting issue, maybe the easiest thing would simply be to say
by fiat that only notes in a LOGBOOK drawer were eligible for special
parsing. If you're sticking notes in the subtree body, they're just a
list. Since no special note-handling facilities currently exist, no one
would lose out on anything if we said any future such facilities would
require the LOGBOOK.

Eric

Re: [feature request] A new cookie type [!] showing the last note taken

[Nicolas Goaziou]

Hello,

Ihor Radchenko <yantar92@gmail.com> writes:

> You are right. I missed that \\ is also a newline for LaTeX export.

It is a line break in any export back-end.

> Another possibility is re-purposing counter definition from ordered
> lists. Currently the "\\[@[0-9]+\\]" is used to force item number in
> ordered lists:
>
> 1. item
> 5. [@5] another item
> 6. next item
>
> However, it is unused it unordered lists. We might define a note as a
> unnumbered list item with [@note]:
>
> - [@note] This is note

That's a reasonable syntax extension, maybe too English-centered. Maybe
a more abstract [@!] would be better.

> In addition, all the list items in :LOGBOOK: drawer may be considered
> notes (to avoid a need to change the current format of the
> automatically added notes).

Notes are not necessary stuffed into a LOGBOOK drawer, or even into
a drawer at all. Besides, LOGBOOK is a common word, and it is not
unreasonable to think some user could have used it for other purposes.

Old notes are going to be incompatible (as in ignored by any tool
processing notes, not invalid markup) with the new ones. I don't think
there's a way to eschew it. It doesn't seem to be a big deal, however,
as you don't lose anything by keeping notes in old syntax around.

Regards,
-- 
Nicolas Goaziou

Re: [feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

>> You are right. I missed that \\ is also a newline for LaTeX export.
>
> It is a line break in any export back-end.

I did not know this and I cannot find any reference about such behaviour
in manual (info:org#Markup for Rich Contents).

>> However, it is unused it unordered lists. We might define a note as a
>> unnumbered list item with [@note]:
>>
>> - [@note] This is note
>
> That's a reasonable syntax extension, maybe too English-centered. Maybe
> a more abstract [@!] would be better.

It also looks better for me.
Should I open separate bug report proposing this syntax extension?

>> In addition, all the list items in :LOGBOOK: drawer may be considered
>> notes (to avoid a need to change the current format of the
>> automatically added notes).
>
> Notes are not necessary stuffed into a LOGBOOK drawer, or even into
> a drawer at all. Besides, LOGBOOK is a common word, and it is not
> unreasonable to think some user could have used it for other purposes.
>
> Old notes are going to be incompatible (as in ignored by any tool
> processing notes, not invalid markup) with the new ones. I don't think
> there's a way to eschew it. It doesn't seem to be a big deal, however,
> as you don't lose anything by keeping notes in old syntax around.

That said, if we decide about the new syntax, it might be a good idea to
provide command converting items inside LOGBOOK drawers into notes.

Best,
Ihor

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> You are right. I missed that \\ is also a newline for LaTeX export.
>
> It is a line break in any export back-end.
>
>> Another possibility is re-purposing counter definition from ordered
>> lists. Currently the "\\[@[0-9]+\\]" is used to force item number in
>> ordered lists:
>>
>> 1. item
>> 5. [@5] another item
>> 6. next item
>>
>> However, it is unused it unordered lists. We might define a note as a
>> unnumbered list item with [@note]:
>>
>> - [@note] This is note
>
> That's a reasonable syntax extension, maybe too English-centered. Maybe
> a more abstract [@!] would be better.
>
>> In addition, all the list items in :LOGBOOK: drawer may be considered
>> notes (to avoid a need to change the current format of the
>> automatically added notes).
>
> Notes are not necessary stuffed into a LOGBOOK drawer, or even into
> a drawer at all. Besides, LOGBOOK is a common word, and it is not
> unreasonable to think some user could have used it for other purposes.
>
> Old notes are going to be incompatible (as in ignored by any tool
> processing notes, not invalid markup) with the new ones. I don't think
> there's a way to eschew it. It doesn't seem to be a big deal, however,
> as you don't lose anything by keeping notes in old syntax around.
>
> Regards,
> -- 
> Nicolas Goaziou

Re: [feature request] A new cookie type [!] showing the last note taken

[Nicolas Goaziou]

Hello,

Ihor Radchenko <yantar92@gmail.com> writes:

> I did not know this and I cannot find any reference about such behaviour
> in manual (info:org#Markup for Rich Contents).

You can find it looking for "line break" in the index. It points there:
(info "(org) Paragraphs").

>>> However, it is unused it unordered lists. We might define a note as a
>>> unnumbered list item with [@note]:
>>>
>>> - [@note] This is note
>>
>> That's a reasonable syntax extension, maybe too English-centered. Maybe
>> a more abstract [@!] would be better.
>
> It also looks better for me.
> Should I open separate bug report proposing this syntax extension?

Thinking again about it, I'm not sold about this idea. Is extending the
syntax the way to go? 

Sure, in the proposal above, it is relatively cheap. But what is the
meaning of an item marked as a "note"? Everything in an entry could be
a note; this is not limited to items. Moreover, if we are considering it
to be a note just because it was automatically inserted using
`org-add-log-note', then we are binding the tool to the syntax. This is
a mistake.

I would like to reconsider the solution to your use case. With a non-nil
value for `org-log-into-drawer', it is possible to guess the location of
the last inserted note, assuming manually inserted ones—if there is
any—also follow the same pattern. Under such a reasonable configuration,
it should not be too difficult to write a function extracting the last
note, or a whole library operating on notes (ideas: move log-related
functions to a new "org-log.el" library, simplify it using Org Capture
as the machinery, extend it…).

Maybe I got lost in this long thread, but what are we really missing
here? Possibly a generic solution, but do we really need one? If you
want to access programmatically to notes, don't set
`org-log-into-drawer' to nil.

Regards,
-- 
Nicolas Goaziou

Re: [feature request] A new cookie type [!] showing the last note taken

[Eric Abrahamsen]

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

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> I did not know this and I cannot find any reference about such behaviour
>> in manual (info:org#Markup for Rich Contents).
>
> You can find it looking for "line break" in the index. It points there:
> (info "(org) Paragraphs").
>
>>>> However, it is unused it unordered lists. We might define a note as a
>>>> unnumbered list item with [@note]:
>>>>
>>>> - [@note] This is note
>>>
>>> That's a reasonable syntax extension, maybe too English-centered. Maybe
>>> a more abstract [@!] would be better.
>>
>> It also looks better for me.
>> Should I open separate bug report proposing this syntax extension?
>
> Thinking again about it, I'm not sold about this idea. Is extending the
> syntax the way to go? 
>
> Sure, in the proposal above, it is relatively cheap. But what is the
> meaning of an item marked as a "note"? Everything in an entry could be
> a note; this is not limited to items. Moreover, if we are considering it
> to be a note just because it was automatically inserted using
> `org-add-log-note', then we are binding the tool to the syntax. This is
> a mistake.
>
> I would like to reconsider the solution to your use case. With a non-nil
> value for `org-log-into-drawer', it is possible to guess the location of
> the last inserted note, assuming manually inserted ones—if there is
> any—also follow the same pattern. Under such a reasonable configuration,
> it should not be too difficult to write a function extracting the last
> note, or a whole library operating on notes (ideas: move log-related
> functions to a new "org-log.el" library, simplify it using Org Capture
> as the machinery, extend it…).

Here's code I've had in my config for quite a while. It gets the
logbook, and shows the most recent item, bound to "V" in the agenda. It
also includes an aborted function to do more thorough parsing of the log
items -- I abandoned that because it was too gross.

I actually also have a library called org-log.el around here somewhere,
but that does quantitative logging of values, which I don't think has
enough general interest. But I'm attaching that, too, just in case.

Anyway, I'd be happy to work on this.

(defun org-get-log-list ()
  "Return the entry's log items, or nil.
The items are returned as a list of 'item elements."
  (save-excursion
    (goto-char (org-log-beginning))
    (let* ((el (org-element-at-point))
	   list-string list-items)
      ;; Should we try harder to make sure it's actually the log list?
      (when (eq (org-element-type el) 'plain-list)
	(setq list-string
	      (buffer-substring
	       (org-element-property :contents-begin el)
	       (org-element-property :contents-end el)))
	(with-temp-buffer
	  (insert list-string)
	  (setq list-items
		(org-element-map
		    (org-element-parse-buffer)
		    'item #'identity))))
      list-items)))

(defun org-agenda-show-log-item ()
  "Echo the text of the entry's most recent log note."
  (interactive)
  (let (log-list item)
    (org-agenda-with-point-at-orig-entry
     nil (setq log-list (org-get-log-list)))
    (if (not log-list)
	(message "Entry has no log")
      (setq item
	    (if org-log-states-order-reversed
		(car log-list)
	      (last log-list)))
      (message (org-element-interpret-data
		(org-element-contents item))))))

(with-eval-after-load 'org-agenda
  (org-defkey org-agenda-mode-map "V" 'org-agenda-show-log-item))

(defun org-parse-log-list (log-list)
  "Turn a parsed plain log list (as returned by
  `org-get-log-list') into something more interesting.

Specifically, this means to extract information from the plain
text of each log item, and put it onto the item's property
list.  Right now this function extracts  "
  (mapcar
   (lambda (item)
     (let* ((pars (org-element-map item 'paragraph #'identity))
	    (head-par (car pars))
	    ;; This is absolutely horrible: assume that, if the first
	    ;; four characters of the log note heading match a value
	    ;; from `org-log-note-headings', then that's the kind of
	    ;; heading we've got.
	    (horrible (mapcar
		       (lambda (x) (cons (car x) (substring (cdr x) 0 3)))
		       org-log-note-headings))
	    (item-type (or (rassoc (substring head-par 0 3) horrible)
			   'uncertain))
	    (timestamp (car-safe (org-element-map head-par 'timestamp #'identity)))
	    state-from state-to schedule deadline)
       (cond ((eq item-type 'state)
	      (setq state-to
		    (and (string-match "State \\([^[:space:]]*\\) " head-par)
			 (match-string 1 head-par)))
	      (setq state-from
		    (and (string-match "from \\([^[:space:]]*\\) " head-par)
			 (match-string 1 head-par)))
	      ))))
   log-list))

[-- Attachment #2: org-log.el --]
[-- Type: text/plain, Size: 5320 bytes --]

;;; org-log.el --- Quantitative logging for Org headings  -*- lexical-binding: t; -*-

;; Copyright (C) 2019  Free Software Foundation, Inc.

;; Author: Eric Abrahamsen <eric@ericabrahamsen.net>
;; Maintainer: Eric Abrahamsen <eric@ericabrahamsen.net>

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:

;; This library provides hooks and functions for quantitative logging
;; in Org: meaning that storing a log note may prompt for one or more
;; quantitative values, and store them as part of the note.  Those
;; values can later be viewed as tables.  Essentially this is a
;; generalization of org-clock, to allow logging of other values.
;; Like org-clock, it also includes a command to view logged data as
;; an Org table.

;; In terms of format, a logged value appears as an all-caps label,
;; followed by a colon, followed by the data itself, followed by a
;; semi-colon.  For instance:

;; BP: 120/60; PULSE: 45;

;; The `org-log-buffer-setup-hook' is used to prompt the user for log
;; values to store.  It does this by looking for a LOG_VALUES property
;; on the heading, which should be a space-separated list of all-caps
;; value labels.  These labels can also contain information about the
;; units used for the value.  Units are specified immediately after
;; the value label in square brackets, like so:

;; DISTANCE[mi]

;; This unit information will be automatically incorporated into
;; tables created to view logged data.  Call the
;; `calc-view-units-table' command to see all valid units; you can
;; define new units using `calc-define-unit', which see.

;;; Code:

(require 'org)
(require 'calc-units)

(defun org-log-prompt ()
  "Prompt the user for log values.
Insert values into the current log note."
  ;; This is called in the log buffer.  Only fire for state and note;
  ;; later add clock-out.
  (when (memq org-log-note-purpose '(state note))
    (let ((values
	   (with-current-buffer (marker-buffer org-log-note-marker)
	     (save-excursion
	       (goto-char org-log-note-marker)
	       (org-entry-get (point) "LOG_VALUES" 'selective)))))
      (when (and (stringp values) (null (string-empty-p values)))
	(unless (bolp)		     ; This might follow a clock line.
	  (insert "; "))
	(dolist (val (split-string values))
	  ;; Maybe strip off units.
	  (setq val (substring val 0 (string-match-p "\\[" val)))
	  (insert val ": ")
	  (insert (read-string (format "%s: " val)) "; "))))))

(defun org-log--collect-data (id)
  "Collect log data from heading with id ID.
When valid data is found, it is returned as a list of lists.
Each sublist starts with the timestamp of the log entry, followed
by data keys and values, in the order they were found in the log
entry.

If no valid data is found, return nil."
  (save-excursion
    (org-id-goto id)
    (goto-char (org-log-beginning))
    (let* ((struct (org-list-struct))
	   (labels (org-entry-get (point) "LOG_VALUES" 'selective))
	   (entries (when (and (stringp labels)
			       (null (string-empty-p labels)))
		      ;; First element is a list of value labels.
		      (list (cons "TIMESTAMP"
				  (mapcar (lambda (str)
					    (substring
					     str 0 (string-match-p "\\[" str)))
					  (split-string labels))))))
	   elt data)
      (when (and entries struct)
	;; Get onto the list item.
	(forward-char)
	(while (equal 'item (org-element-type
			     (setq elt (org-element-at-point))))
	  ;; Move past state/timestamp line.
	  (forward-line)
	  (while (re-search-forward "[[:upper:]]+: \\([^;]+\\)"
				    (point-at-eol) t)
	    (push (match-string-no-properties 1) data))
	  (when data
	    (save-excursion
	      (forward-line -1)
	      ;; Get the log entry timestamp.
	      (setq data
		    (cons (if (re-search-forward org-ts-regexp-inactive
						 (point-at-eol) t)
			      (match-string-no-properties 0)
			    "none")
			  (nreverse data))))
	    (push data entries)
	    (setq data nil))
	  (goto-char (org-element-property :end elt)))
	(nreverse entries)))))

(defun org-log-create-dblock ()
  "Create a dblock with a table for this heading's log data."
  (interactive)
  (let ((id (org-id-get-create)))
    ;; Anyway, this call is the heart of it.
    (org-create-dblock
     `(:name "log" :id ,id))
    (org-update-dblock)))

(defun org-dblock-write:log (params)
  "Write the log dblock table."
  (let ((data (org-log--collect-data (plist-get params :id))))
    (when data
      (save-excursion
	(insert
	 (format "|%s|\n" (mapconcat #'capitalize (pop data) "|"))
	 "|-|\n"
	 (mapconcat (lambda (row)
		      (format "|%s|" (mapconcat #'identity row "|")))
		    data "\n")))
      (org-table-align))))

(add-hook 'org-log-buffer-setup-hook #'org-log-prompt)

(provide 'org-log)
;;; org-log.el ends here

Re: [feature request] A new cookie type [!] showing the last note taken

[Christopher Miles]

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


I think this is possible through read last note text in logbook, then display it
in headline through text-property overlay.

That's what I did in this package [[https://github.com/stardiviner/org-link-beautify]]

Should not be that hard to implement it.

Ihor Radchenko <yantar92@gmail.com> writes:

> Over the years of using Org I often have a need to add a short note
> about how to proceed with some task:
>
> ***** REVIEW check again, subscribe | sindresorhus/awesome: 😎 Awesome lists about all kinds of interesting topics :BOOKMARK:
> :PROPERTIES:
> :CREATED: [2020-03-15 Sun 18:59]
> :Source: https://github.com/sindresorhus/awesome
> :END:
> :LOGBOOK:
> CLOCK: [2020-03-17 Tue 16:18]--[2020-03-17 Tue 17:46] =>  1:28
> CLOCK: [2020-03-17 Tue 16:03]--[2020-03-17 Tue 16:18] =>  0:15
> - Refiled on [2020-03-16 Mon 23:59]
> :END:
>
> In the above example, the short note is "check again, subscribe".
> The note is not fixed, but changes as I progress with completing the
> task.
>
> This is even more useful for delegated or HOLD tasks where I often need
> to add a short note why the task is delegated or put on hold:
>
> ** HOLD Finish the text prop org-mode | make babel support org file links in header args (:file or :dir) [[id:468e0645-68aa-4e14-86de-e5ce153538e3][[2017-09-22 Fri] CuNbARBshearstrength]] :HOLD:
> :PROPERTIES:
> :CREATED: [2020-07-20 Mon 16:53]
> :SHOWFROMDATE: 2020-08-15
> :END:
> :LOGBOOK:
> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> Seeing this note directly in the headline without a need to dig into the
> task body / LOGBOOK drawer is really handy.
>
> In this last example, I had to duplicate the note taken using built-in
> note mechanism into headline, which was inconvenient. It would be handy
> if I could simply add a [!] cookie (similar to [/] or [%] cookies) to
> the headline to show the last note taken for this task. Then, I could
> easily see the reason why the task is blocked or what I am supposed to
> do with the task right in agenda view or in the folded headline.
> Something like the following
>
> ** HOLD [!] make babel support org... :HOLD:
> :LOGBOOK:
> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> The cookie would be replaced by the last note text, according to
> user-defined format (say, "[%s] |"):
>
> ** HOLD [Finish the text prop org-mode] | make babel support org... :HOLD:
> :LOGBOOK:
> - State "HOLD"       from "NEXT"          [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> What do you think?
>
> Best,
> Ihor


-- 
[ stardiviner ]
       I try to make every word tell the meaning that I want to express.

       Blog: https://stardiviner.github.io/
       IRC(freenode): stardiviner, Matrix: stardiviner
       GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

Christopher Miles <numbchild@gmail.com> writes:

> I think this is possible through read last note text in logbook, then display it
> in headline through text-property overlay.
>
> That's what I did in this package [[https://github.com/stardiviner/org-link-beautify]]
>
> Should not be that hard to implement it.

Thanks for the suggestion. However, I think that it would be more
consistent to keep the same approach with other cookie types in org.
They do not use overlays, but change text directly.

Best,
Ihor