Re: Automatically authenticating at local imap server

[Ted Zlatanov]

On Mon, 04 Feb 2008 23:22:38 +0100 David <de_bb@arcor.de> wrote: 

D> Tassilo Horn <tassilo@member.fsf.org> writes:
>> But one thing is left: Is there a way to jump from a message in the
>> search result group to the original nnimap group?  I often do a search
>> to find a message I want to reply to and the reply has to be done from
>> the original group so that posting styles and group parameters are
>> considered.

D> That's on the TODO list - I always wanted a function that jumps to the
D> original message in the original group, but it's not trivial to do. My
D> idea was to call mairix with "m:<MID>", where MID is the message-id of
D> the article. Using the "-r" option, we get the full path of the mail
D> file and it should be possible to uniquely identify the group from the
D> path (the problem here is that the user might index several different
D> mail back ends with one mairix installation). Jumping to the original
D> message in this group is another problem since we only know the
D> message-id but not the article number. nnmaildir and nnml support
D> fetching articles by message-id, but AFAIK nnimap does not. Maybe it is
D> somehow possible to apply the correct posting style even when replying
D> from the nnmairix group, then we wouldn't have to get the original
D> article in the first place.

You could use the Gnus registry if it's loaded.  It will tell you the
last place a message ID was seen (it learns this by looking at the
visible messages every time you enter a group, and by hooking into
spool/move/copy/delete on each backend).  It may not know the location
for various reasons, e.g. the user limits the size of the registry or
the message hasn't been seen yet, but when the location is available
it's a very quick lookup in a hashtable, probably much faster than
calling mairix to do a search.

The registry doesn't currently record the article number, but it could.
Currently a group name is always a string and anything not a string is
extra (non-location) data, so this is not a trivial change.  Since
article numbers are stable in some backends and not in others, this may
be quite a bit of work to do properly.

Ted