Re: [ANNOUNCE] NNDiary, a diary backend for Gnus.

[Didier Verna <didier@lrde.epita.fr>]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:

> Jody Klymak <jklymak@OCE.ORST.EDU> writes:
>
>> nndiary-request-update-info calculates whether a message is read or
>> not based on the schedule for the message.  It then sets the message
>> as unread - without entering the summary buffer.  Without this nndiary
>> wouldn't be much good at reminding you of appointments.
>
> That's a good point.  Hm.  So, I guess what we want is a
> gnus-backend-request-update-info-hook, and nndiary (or gnus-diary)
> could hang its fancy stuff off of that.
>
> I wonder what Didier is going to think of that...

        Here's my point of view: nndiary is a backend for the same reason as
nndraft is one. That's because the article renewing feature is implemented via
the request-update-info backend function. All features not belonging to the
backend are already part of the upper layer called gnus-diary.

        Giving control on the renewing mecanism to the user for *any* mail
(news ?, perhaps cached ones) is a very natural idea: when I receive and
interesting call for papers in my nnml:virtual-reality group, I'd like it to
pop up from time to time in this very group until the deadline arrives. BTW,
the same applies to draft messages IMO. People might type `C-u a' on a group to
start editing a message, and prefer that the draft stays in this group.

        However, if we want to extract this feature from the backends, we'll
have to change the implementation. It's not reasonable to scan *all* messages
in each group to see if they have to be renewed. We'll have to store this
information somewhere. The ideal case would also be to disconnect the feature
from the update-info routines. In other words, it shouldn't be necessary to
have to type `g' in order to see messages renewed. The use of timers comes to
mind, but I don't currently have a clear view on the complexity of such kind
of implementation.

        Another idea that just came to my mind: if we ever have a global
renewing mechanism, we'd probably like to have special summary lines for these
messages. Let's implement an X-Gnus-Summary-Line-Format header ...


--
Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 44 08 01 99   didier@xemacs.org