At Mon, 23 Aug 2010 11:23:25 -0800, Dave Abrahams wrote: > According to http://www.faqs.org/rfcs/rfc2822.html, it is... but we > might get foiled by the rare message that has multiple parents. I > can't imagine a good reason for the RFC's advice about such messages > to leave out the references: field. > > BTW, it looks like we maybe should be more sophisticated about > gathering UIDs: > http://forum.rebex.net/questions/228/imap-processing-of-mail-header-references-with-multiple-msgids Yes, looking through my archives I realize that this function does not actually work so well. I have lots of messages from others that lack a References header or an In-Reply-To or they have a references header that contains only one entry. It works great on our back-and-forth because WL does the right thing here. > Performance problems are bugs in my book :-) > > > Visiting the filter folder calls > > elmo-folder-synchronize on the filter folder which calls > > elmo-folder-synchronize on the IMAP folder, which calls > > elmo-folder-list-messages, which results in all messages being > > returned. This does not seem strictly necessary, but perhaps it > > is. > > Seems highly unlikely that it's necessary for our use case, at least. Yes, it would be very nice to fix this. Unfortunately my understanding of what the filter folder is doing here is pretty limited. > > Here is a new version of this function. I have bound it to X for the > > time being, and if it is called with C-u it should jump back to where > > you came from. > > Nice! any other substantive changes? Nothing substantial. > We should probably stick the source summary buffer, at least temporarily, neh? I am not sure. wl-summary-goto-folder-subr works whether or not the summary was sticky. Also it does not seem possible to unstick a summary. The behavior of wl-summary-virtual is I think closest to this function & it does not stick the summary, so I lean towards no. best, Erik
Attachment:
pgpNMU9pebPlw.pgp
Description: PGP signature