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

[Josh Huber <huber@alum.wpi.edu>]

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

> 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.

Right, I understood -- sorry I was unclear.

> 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>

Quite odd, eh?

> 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.)

This looks pretty strange, but I guess it's not somehow getting that
character as the group name, otherwise there would be a tab separating
the two fields.  Does anyone else see ^M's in their cache file?

> 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.

Right -- absolutely.  When you said backward compatibility, I thought
you meant allowing older Gnus to function with .nnmail-cache files
generated by the newer versions.

> 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.

Right...

> 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).

This sounds like a step in the right direction.  I'll have to think
about it some more though.

I really think the differentiation between the primary server and the
secondary servers to be one of the more confusing/annoying things
about gnus.

Personally, requiring the prefix (i.e. "nnml:") before even the
primary server should be required, or at least used internally.  I'd
like it to be done it such a way that there was no distiction...just
gnus-server-list. (for example).

The user could then have the option to hide the prefix in the group
view, and use group names without the prefix.  If any ambiguities
occured (the same group from different servers) the different part
could be shown in the group buffer.

Of course, this would take a lot of work, and I'm sure there are many
problems lurking which would make this very difficult.

Thoughts?

-- 
Josh Huber