Re: Recursive load? master build fail

[Stephen Berman]

On Wed, 11 May 2016 21:31:12 +0200 Stephen Berman <address@hidden> wrote:

> On Wed, 11 May 2016 21:11:57 +0200 Michael Albinus <address@hidden> wrote:
>
>> Stephen Berman <address@hidden> 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.

Oops:                                         goose

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