Re: [feature request] A new cookie type [!] showing the last note taken
Christopher Miles 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
Re: [feature request] A new cookie type [!] showing the last note taken
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 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 signature.asc Description: PGP signature
Re: [feature request] A new cookie type [!] showing the last note taken
Nicolas Goaziou writes: > Hello, > > Ihor Radchenko 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)))
Re: [feature request] A new cookie type [!] showing the last note taken
Hello, Ihor Radchenko 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
>> 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 writes: > Hello, > > Ihor Radchenko 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
Hello, Ihor Radchenko 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 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 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
> 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
Re: [feature request] A new cookie type [!] showing the last note taken
On Sat, Aug 29, 2020 at 6:42 AM Ihor Radchenko 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
> 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 writes: > Hello, > > Ihor Radchenko 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
Hello, Ihor Radchenko 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
>> - \\ >> > > 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 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 writes: > Hello, > > Ihor Radchenko 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: >> >> - \\ >> > > 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 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
Hello, Ihor Radchenko 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: > > - \\ > 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 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
> 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 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
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
> 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: - \\ The 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 writes: > Ihor Radchenko 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
Nicolas Goaziou writes: > Ihor Radchenko 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
> 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 writes: > Ihor Radchenko 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 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
Ihor Radchenko 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
> 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 writes: > Hello, > > Ihor Radchenko 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
Hello, Ihor Radchenko 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