On Mon, 04 Feb 2008 23:22:38 +0100 David <[EMAIL PROTECTED]> wrote: D> Tassilo Horn <[EMAIL PROTECTED]> 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 _______________________________________________ info-gnus-english mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-gnus-english
