emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* [RFC] Display most recent log item in Agenda
@ 2014-12-14 10:07 Eric Abrahamsen
  2014-12-14 15:12 ` Eric Abrahamsen
  2014-12-14 20:34 ` Nicolas Goaziou
  0 siblings, 2 replies; 14+ messages in thread
From: Eric Abrahamsen @ 2014-12-14 10:07 UTC (permalink / raw)
  To: emacs-orgmode

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

Undeterred by my previous bum patch, I'm sending more patches!

Most of these are "what do you think" patches.

1. Ensure-org-log-into-drawer-returns-nil-or-string

If the answer to my last question is "make sure `org-log-into-drawer'
never returns just t", then this patch does that. If that isn't the
answer, something can be done with `org-log-beginning'.

2. Missing-comma-in-org-agenda-with-point-at-orig-entry

The (currently unused) macro `org-agenda-with-point-at-orig-entry' is
missing a comma.

3. New-function-org-get-log-list and
New-function-org-agenda-show-log-item

This is the "what do you think part". The first patch finds and returns
the state log items of the current entry, as a list of parsed elements.
It probably doesn't try hard enough to make sure it's really found the
list.

The second implements an Agenda command which displays the text of the
most recent note on the entry under point. I use logging a lot, and am
forever looking at "WAIT" or "NEXT" todos, and wondering what the heck I
was waiting for, or actually supposed to do next.

If this is acceptable in principle, the finished product would probably
be a normal org-mode function, with an Agenda implementation on top of
that, and maybe some sort of guard against displaying overly-long notes.

Alternately, I could probably make this into something akin to
org-agenda-entry-text-mode, where *all* entries have their most recent
log item stuck under them. I find that sort of thing distracting, but
some people might like it.

WDYT?

Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Ensure-org-log-into-drawer-returns-nil-or-string.patch --]
[-- Type: text/x-diff, Size: 932 bytes --]

From c8d00f77135022b239e251b9ddde4a4bbffcf110 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Sun, 14 Dec 2014 17:31:49 +0800
Subject: [PATCH 1/4] Ensure org-log-into-drawer returns nil or string

* lisp/org.el (org-log-into-drawer): Don't let it simply return t.
---
 lisp/org.el | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 4aa7988..6df6e2e 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -2969,7 +2969,11 @@ If the current entry has or inherits a LOG_INTO_DRAWER property, it will be
 used instead of the default value."
   (let ((p (org-entry-get nil "LOG_INTO_DRAWER" 'inherit t)))
     (cond
-     ((not p) org-log-into-drawer)
+     ((not p)
+      (when log-into-drawer
+	(if (stringp org-log-into-drawer)
+	    org-log-into-drawer
+	  "LOGBOOK")))
      ((equal p "nil") nil)
      ((equal p "t") "LOGBOOK")
      (t p))))
-- 
2.1.3


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Missing-comma-in-org-agenda-with-point-at-orig-entry.patch --]
[-- Type: text/x-diff, Size: 1012 bytes --]

From cc386175a8a6cc7d1606bbc6c1c47589f95f8ac2 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Sun, 14 Dec 2014 17:30:49 +0800
Subject: [PATCH 2/4] Missing comma in org-agenda-with-point-at-orig-entry

* lisp/org-agenda.el (org-agenda-with-point-at-orig-entry): Fix
  backquote structure.
---
 lisp/org-agenda.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 5990bbb..529cd0e 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -2004,7 +2004,7 @@ If STRING is non-nil, the text property will be fetched from position 0
 in that string.  If STRING is nil, it will be fetched from the beginning
 of the current line."
   (org-with-gensyms (marker)
-    `(let ((,marker (get-text-property (if string 0 (point-at-bol))
+    `(let ((,marker (get-text-property (if ,string 0 (point-at-bol))
 				       'org-hd-marker ,string)))
        (with-current-buffer (marker-buffer ,marker)
 	 (save-excursion
-- 
2.1.3


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-New-function-org-get-log-list.patch --]
[-- Type: text/x-diff, Size: 1500 bytes --]

From 79ebf2977ff54d4160c53f42a7a4bb25b59583a8 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Sun, 14 Dec 2014 17:33:00 +0800
Subject: [PATCH 3/4] New function org-get-log-list

* lisp/org.el (org-get-log-list): Returns the items in an entry's log
  list.
---
 lisp/org.el | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 6df6e2e..0e750e1 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13641,6 +13641,27 @@ narrowing."
 	   (forward-line)))))
      (if (bolp) (point) (line-beginning-position 2)))))
 
+(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-add-log-setup (&optional purpose state prev-state findpos how extra)
   "Set up the post command hook to take a note.
 If this is about to TODO state change, the new state is expected in STATE.
-- 
2.1.3


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-New-function-org-agenda-show-log-item.patch --]
[-- Type: text/x-diff, Size: 1916 bytes --]

From 565858ac1316ffb91be7b1fec8459da93a1670a8 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Sun, 14 Dec 2014 17:33:55 +0800
Subject: [PATCH 4/4] New function org-agenda-show-log-item

* lisp/org-agenda.el (org-agenda-show-log-item): Function to echo an
  entry's most recent log item in the message area. Bind to "V" in the
  agenda keymap.
---
 lisp/org-agenda.el | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 529cd0e..0063b31 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -2247,6 +2247,7 @@ The following commands are available:
 (org-defkey org-agenda-mode-map "E" 'org-agenda-entry-text-mode)
 (org-defkey org-agenda-mode-map "l" 'org-agenda-log-mode)
 (org-defkey org-agenda-mode-map "v" 'org-agenda-view-mode-dispatch)
+(org-defkey org-agenda-mode-map "V" 'org-agenda-show-log-item)
 (org-defkey org-agenda-mode-map "D" 'org-agenda-toggle-diary)
 (org-defkey org-agenda-mode-map "!" 'org-agenda-toggle-deadlines)
 (org-defkey org-agenda-mode-map "G" 'org-agenda-toggle-time-grid)
@@ -8844,6 +8845,21 @@ the same tree node, and the headline of the tree node in the Org-mode file."
 	     (org-flag-heading nil)))   ; show the next heading
       (org-add-note))))
 
+(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))))))
+
 (defun org-agenda-change-all-lines (newhead hdmarker
 					    &optional fixface just-this)
   "Change all lines in the agenda buffer which match HDMARKER.
-- 
2.1.3


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-14 10:07 [RFC] Display most recent log item in Agenda Eric Abrahamsen
@ 2014-12-14 15:12 ` Eric Abrahamsen
  2014-12-14 20:34 ` Nicolas Goaziou
  1 sibling, 0 replies; 14+ messages in thread
From: Eric Abrahamsen @ 2014-12-14 15:12 UTC (permalink / raw)
  To: emacs-orgmode

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

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Undeterred by my previous bum patch, I'm sending more patches!
>
> Most of these are "what do you think" patches.
>
> 1. Ensure-org-log-into-drawer-returns-nil-or-string
>
> If the answer to my last question is "make sure `org-log-into-drawer'
> never returns just t", then this patch does that. If that isn't the
> answer, something can be done with `org-log-beginning'.

Nope, I just shouldn't be posting patches today. One should not code
while hungover. Fixed patch attached.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Ensure-org-log-into-drawer-returns-nil-or-string.patch --]
[-- Type: text/x-diff, Size: 936 bytes --]

From c99d6065ae25d927a395f9aed611fab22b8e40c9 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Sun, 14 Dec 2014 17:31:49 +0800
Subject: [PATCH 1/4] Ensure org-log-into-drawer returns nil or string

* lisp/org.el (org-log-into-drawer): Don't let it simply return t.
---
 lisp/org.el | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 4aa7988..db5810d 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -2969,7 +2969,11 @@ If the current entry has or inherits a LOG_INTO_DRAWER property, it will be
 used instead of the default value."
   (let ((p (org-entry-get nil "LOG_INTO_DRAWER" 'inherit t)))
     (cond
-     ((not p) org-log-into-drawer)
+     ((not p)
+      (when org-log-into-drawer
+	(if (stringp org-log-into-drawer)
+	    org-log-into-drawer
+	  "LOGBOOK")))
      ((equal p "nil") nil)
      ((equal p "t") "LOGBOOK")
      (t p))))
-- 
2.1.3


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



> 2. Missing-comma-in-org-agenda-with-point-at-orig-entry
>
> The (currently unused) macro `org-agenda-with-point-at-orig-entry' is
> missing a comma.
>
> 3. New-function-org-get-log-list and
> New-function-org-agenda-show-log-item
>
> This is the "what do you think part". The first patch finds and returns
> the state log items of the current entry, as a list of parsed elements.
> It probably doesn't try hard enough to make sure it's really found the
> list.
>
> The second implements an Agenda command which displays the text of the
> most recent note on the entry under point. I use logging a lot, and am
> forever looking at "WAIT" or "NEXT" todos, and wondering what the heck I
> was waiting for, or actually supposed to do next.
>
> If this is acceptable in principle, the finished product would probably
> be a normal org-mode function, with an Agenda implementation on top of
> that, and maybe some sort of guard against displaying overly-long notes.
>
> Alternately, I could probably make this into something akin to
> org-agenda-entry-text-mode, where *all* entries have their most recent
> log item stuck under them. I find that sort of thing distracting, but
> some people might like it.
>
> WDYT?
>
> Eric

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-14 10:07 [RFC] Display most recent log item in Agenda Eric Abrahamsen
  2014-12-14 15:12 ` Eric Abrahamsen
@ 2014-12-14 20:34 ` Nicolas Goaziou
  2014-12-15  1:34   ` Eric Abrahamsen
  2014-12-15  4:29   ` Eric Abrahamsen
  1 sibling, 2 replies; 14+ messages in thread
From: Nicolas Goaziou @ 2014-12-14 20:34 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

Hello,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Undeterred by my previous bum patch, I'm sending more patches!
>
> Most of these are "what do you think" patches.
>
> 1. Ensure-org-log-into-drawer-returns-nil-or-string
>
> If the answer to my last question is "make sure `org-log-into-drawer'
> never returns just t", then this patch does that. If that isn't the
> answer, something can be done with `org-log-beginning'.

I applied something similar. Thank you.

> 2. Missing-comma-in-org-agenda-with-point-at-orig-entry
>
> The (currently unused) macro `org-agenda-with-point-at-orig-entry' is
> missing a comma.
>
> 3. New-function-org-get-log-list and
> New-function-org-agenda-show-log-item
>
> This is the "what do you think part". The first patch finds and returns
> the state log items of the current entry, as a list of parsed elements.
> It probably doesn't try hard enough to make sure it's really found the
> list.
>
> The second implements an Agenda command which displays the text of the
> most recent note on the entry under point. I use logging a lot, and am
> forever looking at "WAIT" or "NEXT" todos, and wondering what the heck I
> was waiting for, or actually supposed to do next.
>
> If this is acceptable in principle, the finished product would probably
> be a normal org-mode function, with an Agenda implementation on top of
> that, and maybe some sort of guard against displaying overly-long
> notes.

[...]

> WDYT?

I think the feature is interesting. However, the implementation seems
inefficient. Why do you need to parse all log entries if all you're
interested in is the last one? Parsing the last one should be
sufficient.

Better, you could store the last note as a text property on the headline
and skip altogether the parsing phase.

WDYT?


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-14 20:34 ` Nicolas Goaziou
@ 2014-12-15  1:34   ` Eric Abrahamsen
  2014-12-15 12:43     ` Nicolas Goaziou
  2014-12-15  4:29   ` Eric Abrahamsen
  1 sibling, 1 reply; 14+ messages in thread
From: Eric Abrahamsen @ 2014-12-15  1:34 UTC (permalink / raw)
  To: emacs-orgmode

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Undeterred by my previous bum patch, I'm sending more patches!
>>
>> Most of these are "what do you think" patches.
>>
>> 1. Ensure-org-log-into-drawer-returns-nil-or-string
>>
>> If the answer to my last question is "make sure `org-log-into-drawer'
>> never returns just t", then this patch does that. If that isn't the
>> answer, something can be done with `org-log-beginning'.
>
> I applied something similar. Thank you.
>
>> 2. Missing-comma-in-org-agenda-with-point-at-orig-entry
>>
>> The (currently unused) macro `org-agenda-with-point-at-orig-entry' is
>> missing a comma.
>>
>> 3. New-function-org-get-log-list and
>> New-function-org-agenda-show-log-item
>>
>> This is the "what do you think part". The first patch finds and returns
>> the state log items of the current entry, as a list of parsed elements.
>> It probably doesn't try hard enough to make sure it's really found the
>> list.
>>
>> The second implements an Agenda command which displays the text of the
>> most recent note on the entry under point. I use logging a lot, and am
>> forever looking at "WAIT" or "NEXT" todos, and wondering what the heck I
>> was waiting for, or actually supposed to do next.
>>
>> If this is acceptable in principle, the finished product would probably
>> be a normal org-mode function, with an Agenda implementation on top of
>> that, and maybe some sort of guard against displaying overly-long
>> notes.
>
> [...]
>
>> WDYT?
>
> I think the feature is interesting. However, the implementation seems
> inefficient. Why do you need to parse all log entries if all you're
> interested in is the last one? Parsing the last one should be
> sufficient.

I started with this approach for two reasons: 1) I thought collecting
the list items would be simpler, and as it became more and more
complicated, I didn't rethink the approach, and 2) collecting all the
items is the actual feature I was after (for future hackage), and the
agenda display was just a nice bonus.

I'd like to keep the collection routine (even just for myself, if it's
not necessary for core), but you're right, the most-recent note display
could be done differently.

> Better, you could store the last note as a text property on the headline
> and skip altogether the parsing phase.

When would the storing happen? As the agenda was being built?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-14 20:34 ` Nicolas Goaziou
  2014-12-15  1:34   ` Eric Abrahamsen
@ 2014-12-15  4:29   ` Eric Abrahamsen
  2014-12-15 12:33     ` Nicolas Goaziou
  1 sibling, 1 reply; 14+ messages in thread
From: Eric Abrahamsen @ 2014-12-15  4:29 UTC (permalink / raw)
  To: emacs-orgmode

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Undeterred by my previous bum patch, I'm sending more patches!
>>
>> Most of these are "what do you think" patches.
>>
>> 1. Ensure-org-log-into-drawer-returns-nil-or-string
>>
>> If the answer to my last question is "make sure `org-log-into-drawer'
>> never returns just t", then this patch does that. If that isn't the
>> answer, something can be done with `org-log-beginning'.
>
> I applied something similar. Thank you.

I think this still isn't quite right. If the variable
`org-log-into-drawer' is set to t, and the entry has no logdrawer
property, the whole function still returns the t, which breaks
`org-log-beginning'.

>> 2. Missing-comma-in-org-agenda-with-point-at-orig-entry
>>
>> The (currently unused) macro `org-agenda-with-point-at-orig-entry' is
>> missing a comma.
>>
>> 3. New-function-org-get-log-list and
>> New-function-org-agenda-show-log-item
>>
>> This is the "what do you think part". The first patch finds and returns
>> the state log items of the current entry, as a list of parsed elements.
>> It probably doesn't try hard enough to make sure it's really found the
>> list.
>>
>> The second implements an Agenda command which displays the text of the
>> most recent note on the entry under point. I use logging a lot, and am
>> forever looking at "WAIT" or "NEXT" todos, and wondering what the heck I
>> was waiting for, or actually supposed to do next.
>>
>> If this is acceptable in principle, the finished product would probably
>> be a normal org-mode function, with an Agenda implementation on top of
>> that, and maybe some sort of guard against displaying overly-long
>> notes.
>
> [...]
>
>> WDYT?
>
> I think the feature is interesting. However, the implementation seems
> inefficient. Why do you need to parse all log entries if all you're
> interested in is the last one? Parsing the last one should be
> sufficient.
>
> Better, you could store the last note as a text property on the headline
> and skip altogether the parsing phase.
>
> WDYT?
>
>
> Regards,

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-15  4:29   ` Eric Abrahamsen
@ 2014-12-15 12:33     ` Nicolas Goaziou
  0 siblings, 0 replies; 14+ messages in thread
From: Nicolas Goaziou @ 2014-12-15 12:33 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I think this still isn't quite right. If the variable
> `org-log-into-drawer' is set to t, and the entry has no logdrawer
> property, the whole function still returns the t, which breaks
> `org-log-beginning'.

Indeed. Fixed. Thank you.


Regards,

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-15  1:34   ` Eric Abrahamsen
@ 2014-12-15 12:43     ` Nicolas Goaziou
  2014-12-16  2:26       ` Eric Abrahamsen
  0 siblings, 1 reply; 14+ messages in thread
From: Nicolas Goaziou @ 2014-12-15 12:43 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I started with this approach for two reasons: 1) I thought collecting
> the list items would be simpler, and as it became more and more
> complicated, I didn't rethink the approach, and 2) collecting all the
> items is the actual feature I was after (for future hackage), and the
> agenda display was just a nice bonus.

OK.

> I'd like to keep the collection routine (even just for myself, if it's
> not necessary for core), but you're right, the most-recent note display
> could be done differently.

Collecting is fine, but instead of using `org-log-beginning', I suggest
to factor out parts you need (e.g. find the log drawer, if any).

Note that if `org-log-into-drawer' is nil, you can only find all notes
heuristically (they might be scattered across the section). In this
case, finding the last note is safer.

>> Better, you could store the last note as a text property on the headline
>> and skip altogether the parsing phase.
>
> When would the storing happen? As the agenda was being built?

When the storing is done, i.e. after calling `org-store-log-note'.
However, you would need persistent data to save log notes across
sessions. So it isn't a good idea after all.


Regards,

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-15 12:43     ` Nicolas Goaziou
@ 2014-12-16  2:26       ` Eric Abrahamsen
  2014-12-16  9:10         ` Nicolas Goaziou
  0 siblings, 1 reply; 14+ messages in thread
From: Eric Abrahamsen @ 2014-12-16  2:26 UTC (permalink / raw)
  To: emacs-orgmode

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I started with this approach for two reasons: 1) I thought collecting
>> the list items would be simpler, and as it became more and more
>> complicated, I didn't rethink the approach, and 2) collecting all the
>> items is the actual feature I was after (for future hackage), and the
>> agenda display was just a nice bonus.
>
> OK.
>
>> I'd like to keep the collection routine (even just for myself, if it's
>> not necessary for core), but you're right, the most-recent note display
>> could be done differently.
>
> Collecting is fine, but instead of using `org-log-beginning', I suggest
> to factor out parts you need (e.g. find the log drawer, if any).
>
> Note that if `org-log-into-drawer' is nil, you can only find all notes
> heuristically (they might be scattered across the section). In this
> case, finding the last note is safer.

I thought that's what `org-log-beginning' was for: finding where the
log-note list would be (drawer or no), if it exists. If users aren't
using `org-log-into-drawer', `org-log-beginning' should still go to the
spot where the list would be, right?

Then, if there's a list there, I take the first or last note (depending
on log-state-notes-reversed).

I don't know why the notes would be scattered across the section...

Slightly confused,
Eric 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-16  2:26       ` Eric Abrahamsen
@ 2014-12-16  9:10         ` Nicolas Goaziou
  2014-12-17  7:16           ` Eric Abrahamsen
  2014-12-19  8:50           ` Eric Abrahamsen
  0 siblings, 2 replies; 14+ messages in thread
From: Nicolas Goaziou @ 2014-12-16  9:10 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I thought that's what `org-log-beginning' was for: finding where the
> log-note list would be (drawer or no), if it exists.

Not exactly. It finds where the next note is to be inserted. This may
not be in front of the log-note list even if it exists (e.g., if
`org-log-states-order-reversed' is nil you may end up in front of the
following paragraph).

> If users aren't using `org-log-into-drawer', `org-log-beginning'
> should still go to the spot where the list would be, right?

Not necessarily. It actually doesn't look for such a list. It could end
up after the list (see above) or even in a different location (see
below).

Also, it doesn't tell if there is a list at all, so if you rely on it,
you need to double-check if you really are close to a log-note.

Unfortunately, recognizing a log note is impossible, since it is
a regular plain list. Contents change, and templates are customizables
(see `org-log-note-headings'). See, for example, the hack in
`org-skip-over-state-notes'.

> Then, if there's a list there, I take the first or last note (depending
> on log-state-notes-reversed).
>
> I don't know why the notes would be scattered across the section...

Because in this case, the list is not necessarily re-used. The first
note is inserted after planning info and properties drawer. If, later,
you insert some text before it, logging process will create a new list
above, and so on. E.g.,

Step 1:

  * Headline
    - Note 1

Step 2:

  * Headline
    Some text
    - Note 1

Step 3:

  * Headline
    - Note 2
    Some text
    - Note 1


Regards,

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-16  9:10         ` Nicolas Goaziou
@ 2014-12-17  7:16           ` Eric Abrahamsen
  2014-12-20 21:13             ` Nicolas Goaziou
  2014-12-19  8:50           ` Eric Abrahamsen
  1 sibling, 1 reply; 14+ messages in thread
From: Eric Abrahamsen @ 2014-12-17  7:16 UTC (permalink / raw)
  To: emacs-orgmode

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I thought that's what `org-log-beginning' was for: finding where the
>> log-note list would be (drawer or no), if it exists.
>
> Not exactly. It finds where the next note is to be inserted. This may
> not be in front of the log-note list even if it exists (e.g., if
> `org-log-states-order-reversed' is nil you may end up in front of the
> following paragraph).
>
>> If users aren't using `org-log-into-drawer', `org-log-beginning'
>> should still go to the spot where the list would be, right?
>
> Not necessarily. It actually doesn't look for such a list. It could end
> up after the list (see above) or even in a different location (see
> below).
>
> Also, it doesn't tell if there is a list at all, so if you rely on it,
> you need to double-check if you really are close to a log-note.

Well sure, I was already aware of all this (except I hadn't caught that
`org-log-beginning' would go to the intended location of the *newest
note*, not just the location of the list, thanks for that). There were
also some checks in the code I sent to make sure there was actually a
list in the spot where `org-log-beginning' deposited us.

> Unfortunately, recognizing a log note is impossible, since it is
> a regular plain list. Contents change, and templates are customizables
> (see `org-log-note-headings'). See, for example, the hack in
> `org-skip-over-state-notes'.

I'm not terribly worried about finding the real last state note with
100% accuracy -- as you say, that's not really possible. This would be a
convenience function displaying a useful bit of information, and if it
fails to do so no planes will crash. Anyone who cares enough to use it
probably already knows where their notes are. ("You've got to know where
your towel is.")

I'd be inclined just to go to the location of `org-log-beginning', look
around for likely log notes, show the most recent one if we can find
it, and bail if not. What do you think?

>> Then, if there's a list there, I take the first or last note (depending
>> on log-state-notes-reversed).
>>
>> I don't know why the notes would be scattered across the section...
>
> Because in this case, the list is not necessarily re-used. The first
> note is inserted after planning info and properties drawer. If, later,
> you insert some text before it, logging process will create a new list
> above, and so on. E.g.,
>
> Step 1:
>
>   * Headline
>     - Note 1
>
> Step 2:
>
>   * Headline
>     Some text
>     - Note 1
>
> Step 3:
>
>   * Headline
>     - Note 2
>     Some text
>     - Note 1
>
>
> Regards,

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-16  9:10         ` Nicolas Goaziou
  2014-12-17  7:16           ` Eric Abrahamsen
@ 2014-12-19  8:50           ` Eric Abrahamsen
  2014-12-20 21:02             ` Nicolas Goaziou
  1 sibling, 1 reply; 14+ messages in thread
From: Eric Abrahamsen @ 2014-12-19  8:50 UTC (permalink / raw)
  To: emacs-orgmode

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

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I thought that's what `org-log-beginning' was for: finding where the
>> log-note list would be (drawer or no), if it exists.
>
> Not exactly. It finds where the next note is to be inserted. This may
> not be in front of the log-note list even if it exists (e.g., if
> `org-log-states-order-reversed' is nil you may end up in front of the
> following paragraph).

I keep hammering on this but... There's still a bug in
`org-log-beginning', I think maybe the same one as before. Say it's
called on an empty entry, or one that only contains a property drawer
and/or a planning line, and there's another entry immediately after it,
no blank line. Then we reach this line:

(if (org-at-heading-p) (point)

The test returns true because we're already on the next headline.
(point) is returned as the place to put the new note, without checking
if a drawer should be inserted, too. That means the first note won't go
in a drawer, but all subsequent ones do.

I came up with something that works, but I look forward to seeing a more
elegant solution!

Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-for-org-log-beginning-on-empty-entries.patch --]
[-- Type: text/x-diff, Size: 3175 bytes --]

From 04cea438e69a6b3d8fba060c02d80d2977ff9786 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Fri, 19 Dec 2014 16:48:22 +0800
Subject: [PATCH] Fix for `org-log-beginning' on empty entries

* lisp/org.el (org-log-beginning): Check for the need to insert a
  drawer in all cases.
---
 lisp/org.el | 59 ++++++++++++++++++++++++++++++-----------------------------
 1 file changed, 30 insertions(+), 29 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1383d76..b3d4381 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13613,35 +13613,36 @@ narrowing."
    (when (looking-at org-property-drawer-re)
      (goto-char (match-end 0))
      (forward-line))
-   (if (org-at-heading-p) (point)
-     (let ((end (save-excursion (outline-next-heading) (point)))
-	   (drawer (org-log-into-drawer)))
-       (cond
-	(drawer
-	 (let ((regexp (concat "^[ \t]*:" (regexp-quote drawer) ":[ \t]*$"))
-	       (case-fold-search t))
-	   (catch 'exit
-	     ;; Try to find existing drawer.
-	     (while (re-search-forward regexp end t)
-	       (let ((element (org-element-at-point)))
-		 (when (eq (org-element-type element) 'drawer)
-		   (let ((cend  (org-element-property :contents-end element)))
-		     (when (and (not org-log-states-order-reversed) cend)
-		       (goto-char cend)))
-		   (throw 'exit nil))))
-	     ;; No drawer found.  Create one, if permitted.
-	     (when create
-	       (unless (bolp) (insert "\n"))
-	       (let ((beg (point)))
-		 (insert ":" drawer ":\n:END:\n")
-		 (org-indent-region beg (point)))
-	       (end-of-line -1)))))
-	(org-log-state-notes-insert-after-drawers
-	 (while (and (looking-at org-drawer-regexp)
-		     (progn (goto-char (match-end 0))
-			    (re-search-forward org-property-end-re end t)))
-	   (forward-line)))))
-     (if (bolp) (point) (line-beginning-position 2)))))
+   (let ((end (save-excursion (when (org-at-heading-p)
+				(forward-line -1))
+			      (outline-next-heading) (point)))
+	 (drawer (org-log-into-drawer)))
+     (cond
+      (drawer
+       (let ((regexp (concat "^[ \t]*:" (regexp-quote drawer) ":[ \t]*$"))
+	     (case-fold-search t))
+	 (catch 'exit
+	   ;; Try to find existing drawer.
+	   (while (re-search-forward regexp end t)
+	     (let ((element (org-element-at-point)))
+	       (when (eq (org-element-type element) 'drawer)
+		 (let ((cend  (org-element-property :contents-end element)))
+		   (when (and (not org-log-states-order-reversed) cend)
+		     (goto-char cend)))
+		 (throw 'exit nil))))
+	   ;; No drawer found.  Create one, if permitted.
+	   (when create
+	     (unless (bolp) (insert "\n"))
+	     (let ((beg (point)))
+	       (insert ":" drawer ":\n:END:\n")
+	       (org-indent-region beg (point)))
+	     (end-of-line -1)))))
+      (org-log-state-notes-insert-after-drawers
+       (while (and (looking-at org-drawer-regexp)
+		   (progn (goto-char (match-end 0))
+			  (re-search-forward org-property-end-re end t)))
+	 (forward-line)))))
+   (if (bolp) (point) (line-beginning-position 2))))
 
 (defun org-add-log-setup (&optional purpose state prev-state findpos how extra)
   "Set up the post command hook to take a note.
-- 
2.2.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-19  8:50           ` Eric Abrahamsen
@ 2014-12-20 21:02             ` Nicolas Goaziou
  2014-12-21  4:08               ` Eric Abrahamsen
  0 siblings, 1 reply; 14+ messages in thread
From: Nicolas Goaziou @ 2014-12-20 21:02 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

Hello,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I keep hammering on this but... There's still a bug in
> `org-log-beginning', I think maybe the same one as before. Say it's
> called on an empty entry, or one that only contains a property drawer
> and/or a planning line, and there's another entry immediately after it,
> no blank line. Then we reach this line:
>
> (if (org-at-heading-p) (point)
>
> The test returns true because we're already on the next headline.
> (point) is returned as the place to put the new note, without checking
> if a drawer should be inserted, too. That means the first note won't go
> in a drawer, but all subsequent ones do.
>
> I came up with something that works, but I look forward to seeing a more
> elegant solution!

You're right. Thanks for the patch. I applied something slightly
different, however.


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-17  7:16           ` Eric Abrahamsen
@ 2014-12-20 21:13             ` Nicolas Goaziou
  0 siblings, 0 replies; 14+ messages in thread
From: Nicolas Goaziou @ 2014-12-20 21:13 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I'm not terribly worried about finding the real last state note with
> 100% accuracy -- as you say, that's not really possible. This would be a
> convenience function displaying a useful bit of information, and if it
> fails to do so no planes will crash.

I should try to answer this to bug reports.

More seriously, if the function is using some heuristics to find the
last note, this should be documented somewhere (e.g., a caveat when
`org-log-into-drawer' is nil).

> I'd be inclined just to go to the location of `org-log-beginning', look
> around for likely log notes, show the most recent one if we can find
> it, and bail if not. What do you think?

That's the idea. The tricky part may be "look around for likely log
notes", depending on how hard you want to try.


Regards,

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC] Display most recent log item in Agenda
  2014-12-20 21:02             ` Nicolas Goaziou
@ 2014-12-21  4:08               ` Eric Abrahamsen
  0 siblings, 0 replies; 14+ messages in thread
From: Eric Abrahamsen @ 2014-12-21  4:08 UTC (permalink / raw)
  To: emacs-orgmode

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I keep hammering on this but... There's still a bug in
>> `org-log-beginning', I think maybe the same one as before. Say it's
>> called on an empty entry, or one that only contains a property drawer
>> and/or a planning line, and there's another entry immediately after it,
>> no blank line. Then we reach this line:
>>
>> (if (org-at-heading-p) (point)
>>
>> The test returns true because we're already on the next headline.
>> (point) is returned as the place to put the new note, without checking
>> if a drawer should be inserted, too. That means the first note won't go
>> in a drawer, but all subsequent ones do.
>>
>> I came up with something that works, but I look forward to seeing a more
>> elegant solution!
>
> You're right. Thanks for the patch. I applied something slightly
> different, however.

It's always interesting to see your tweaks...

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2014-12-21  4:03 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-14 10:07 [RFC] Display most recent log item in Agenda Eric Abrahamsen
2014-12-14 15:12 ` Eric Abrahamsen
2014-12-14 20:34 ` Nicolas Goaziou
2014-12-15  1:34   ` Eric Abrahamsen
2014-12-15 12:43     ` Nicolas Goaziou
2014-12-16  2:26       ` Eric Abrahamsen
2014-12-16  9:10         ` Nicolas Goaziou
2014-12-17  7:16           ` Eric Abrahamsen
2014-12-20 21:13             ` Nicolas Goaziou
2014-12-19  8:50           ` Eric Abrahamsen
2014-12-20 21:02             ` Nicolas Goaziou
2014-12-21  4:08               ` Eric Abrahamsen
2014-12-15  4:29   ` Eric Abrahamsen
2014-12-15 12:33     ` Nicolas Goaziou

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).