Re: possible imap.el bug

[Simon Josefsson <jas@extundo.com>]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> On Tue, 26 Oct 2004, jas@extundo.com wrote:
>
>>> Does imap-open have to take a buffer argument?
>> 
>> If not, it will create a new unique one.  I think it is better to name
>> the server " *nnimap* foo", to mimic how nntp do things.
>> 
>>> I would make it always create the buffer, to be safe, and because
>>> reusing the old buffer has no obvious (to me) benefit.
>> 
>> Passwords, stream preferences, and possibly more useful data, are
>> stored in the buffer.  Those can be costly to discover again.
>> Especially since IMAP servers typically throw you out after 30
>> minutes.
>
> Yes, but when it doesn't work that's tough to defend :)

Right, although is anyone but you seeing this?  It could be some weird
interaction with some customization.  Anyway, it doesn't seem right to
change something without knowing what was wrong in the old code.  On
the other hand, if you can come up with a patch that works for you,
and seem harmless, and works for others, I guess there is no major
reason not to apply it, although I feel a bit uneasy about such
changes in general.

> I think that get-buffer-or-create will do the right thing anyhow based
> on the server name in imap-open, so if the buffer already exists it
> will be selected correctly.

I'm not sure.  imap-open name the buffers after the network address,
not after the virtual server name.  Imagine:

(setq gnus-secondary-select-methods
       '((nnimap "foo" (nnimap-address "mail"))
         (nnimap "bar" (nnimap-address "mail"))))

Where, for example, "foo" and "bar" could map to different user names
in ~/.authinfo.  Then there would be a collision of buffer names,
since imap.el would pick the same buffer for both servers.

Only nnimap.el have the virtual server name, that is why it create the
buffer.  Which must be unique among nnimap servers, so it can be
assumed to correspond to the same server later on.  Network addresses
aren't unique enough.

> In general, I don't understand why buffer
> names are stored in the nnimap-server-buffer-alist instead of simply
> generated on the fly.  If that buffer exists already, great.  If not,
> it's no problem either.  The parameter to imap-open may be a "purpose"
> parameter like 'nnimap, which can be used in making the buffer name
> string, but there should be no chance for passing an incorrect buffer
> as is happening now.

Is nnimap passing the incorrect buffer to imap-open?

>>> At some point, it's called with nnimap-server-buffer set to the
>>> wrong buffer but I don't know where.  I do know it happens when many
>>> articles are moved sequentially between IMAP servers.
>> 
>> Maybe the problem is in gnus-move.el?
>> 
>>> I'll keep investigating, but if we can eliminate the buffer argument
>>> to imap-open I think that would make life much easier.
>> 
>> Perhaps you could modify your local copy, temporarily?  If some code
>> is using the wrong buffer, perhaps renaming it will somehow trigger
>> the bug more easily.
>
> I'm not sure what you mean here, what should I debug?

You could modify nnimap and imap locally, to generate buffer names on
the fly, to see if that solve your problem.