emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [RFC] Display most recent log item in Agenda


From: Eric Abrahamsen
Subject: Re: [O] [RFC] Display most recent log item in Agenda
Date: Mon, 15 Dec 2014 09:34:28 +0800
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

Nicolas Goaziou <address@hidden> writes:

> Hello,
>
> Eric Abrahamsen <address@hidden> 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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]