Re: Recursive load? master build fail

[Stephen Berman <stephen.berman@gmx.net>]

On Wed, 11 May 2016 21:11:57 +0200 Michael Albinus <michael.albinus@gmx.de> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>>> I cannot reproduce it here. Does it also happen, when you call "emacs -Q",
>>> and load only gnus specific settings?
>>
>> No, with -Q, `M-x gnus', `n', `B RET news.gmane.org RET', then entering
>> e.g. the group gmane.emacs.bugs and selecting an article with SPC (not
>> RET, as I mistakenly wrote above) works without error.
>
> Ahh, that explains what I'm debugging for hours. Your backtrace tells me
> that Tramp is in completion mode. This couldn't happen when you have
> entered RET as last key. Entering SPC is another story, which makes more
> sense with your backtrace.

So sorry that my mistake sent you on a wild good chase.

> At least now I have an idea what to look for. And maybe I could even
> reproduce it locally, which would help much.

That would be good.  I'm now using Gnus from master and having gotten
the error on first trying to open an article, then using `g' to get the
correct display as I noted in my previous post, I'm now not getting the
error anymore at all.  Maybe a timing or initialization issue?

>> I have no idea what that means.  Do you have any suggestion how to try
>> to debug this?  I can try to bisect my initializations, but that will be
>> laborious; git bisect will probably be even more painful, since building
>> Emacs on this machine is quite slow.
>
> I bet you use something like ido or icicles or so.

I don't use either of these directly, but a command I wrote to access
recentf-list does call ido-completing-read; but I haven't invoked that
command prior to any of the "Recursive load" errors I've seen in Gnus.

Steve Berman