Re: funny problems with nnmail-cache and split-fancy-with-parent

[Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)]

Josh Huber <huber@alum.wpi.edu> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> I'm using nnimap (mainly) and nnml (for just a few messages).
>> .nnmail-cache looks okay wrt the group names: most messages don't
>> mention a group, and some of them mention "inbox" or "spam".  Seems
>> fine, since these are the two nnml groups I use at the moment.
>
> Should I assume you're not using splitting in Gnus to split the IMAP
> articles?  (is this even possible?)

I don't know what you should do :-)

But seriously, I use nnmail-split-methods for the nnml mails, whereas
I use server-side splitting (our Cyrus server supports Sieve) for
nnimap.  (Note that Gnus supports splitting for nnimap, too.  See the
variable nnimap-split-rule¹.)

>> But a sizable number of lines have ^M at the end.  Hm.
>> Anything special I should look for?
>
> That's pretty odd...are these lines with no group listed?  Is there a
> \t after the msgid on those lines?  I'm not really seeing how that
> could happen, unless the group name was somehow "^M" by accident...

Maybe my wording was unclear.  By ^M I mean character number 13, aka
CR.  I don't mean the two characters ^ and M.  I think ascii 13 is
not allowed in group names.

The ^M is at EOL.  So this smells of a DOSish file.  But of course I
have no idea where these characters come from.  Here is a typical ^M
inflicted line:

<vaf661ialiu.fsf@INBOX.auto.emacs.devel.tok.lucy.cs.uni-dortmund.de>

Hm.  Now that I look at the file it seems that most message ids are
from me.  Strange.  And all the ^M lines seem to come from messages I
sent from an nnimap group.  (I have magic in my .gnus file to put a
token in the msg id so that I can file followups in the same group as
their originals.)

>> Another things that's been on my mind for a while is that it might
>> be useful to change the .nnmail-cache format to include the server
>> with the group name.  It is in principle easy to do, but I don't
>> know how to do it in a backward-compatible manner.  Suggestions?
>
> Doing this in a backward-compatible way is going to be hard, I agree.
> Since nnmail-cache-fetch-group does this:
>
>       (when (search-backward id nil t)
> 	(beginning-of-line)
> 	(skip-chars-forward "^\n\r\t")
> 	(unless (eolp)
> 	  (forward-char 1)
> 	  (buffer-substring (point)
> 			    (progn (end-of-line) (point)))))
>
> It's difficult to get it to work...the first thing that comes to mind
> is to add a second line including more information which will never
> get matched as a messageid:
>
> examplemsgid29sdf13499@foo.bar.com	mail.lists.foo
> ***	((group . "mail.lists.foo") (server . (nnml "")))

Hm?  I think you're looking in the wrong place for the problems.  I
think it's entirely sufficient to put group names such as
nnml+private:foo.bar into the file.

The only problem is that the natural interpretation for `bare' group
names is that they come from the primary (native) server.  But this
is clearly not the case for the old group names.

One possibility would be to use the magic string `native' for the
primary server.  Then bare group names could be interpreted as
relative to the primary mail backend (as defined by the current
code).  And all other group names are fully qualified.

Another possibility would be to define a third field.  Lines with
only one field are old lines without group name.  Lines with two
fields are old lines with group name.  Lines with three fields
include the server, where an empty third field could mean the native
server.  Otherwise the third field could have a form such as nnml:foo
(like shown in the server buffer).

Maybe it would be useful for Gnus to define a certain standard as to
what server names should look like.  I'm a bit confused.  Sometimes,
it's nnml:foo, sometimes it's just foo.  People tried to explain to
me before, but I still don't understand.  Must be a thickhead ;-)

Does this rant make any sense at all?  I think I need some rest...

kai
-- 
Silence is foo!