Re: possible imap.el bug

["Ted Zlatanov" <tzz@lifelogs.com>]

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

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

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

Ted