Re: gnus-server-to-method crash on virtual server name in gnus-secondary-select-methods

[Eric Abrahamsen]

Greg Klanderman <gak@klanderman.net> writes:

> Hi Eric,
>
>>>>>> On January 21, 2021 Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>
>>> According to
>>> 
>>> https://www.gnu.org/software/emacs/manual/html_node/gnus/Servers-and-Methods.html
>>> 
>>> not only can you use virtual server names (strings) "wherever you
>>> would normally use a select method", it explicitly states you can do
>>> so in 'gnus-secondary-select-method' (presumably a typo that the final
>>> 's' is missing).
>>> 
>>> So based on that alone, any code which loops over
>>> gnus-secondary-select-methods taking car/cdr of elements is highly
>>> suspicious.  The additional information I gave just demonstrated one
>>> way to reach this problematic logic.
>
>> I still can't believe this is the way it's supposed to be used. The code
>> snippet you posted (where the error actually arises) has been that way
>> since The Dawn of Time. I also don't see why you _would_ define a server
>> via the *Server* buffer, and then put it again in
>> `gnus-secondary-select-methods'. Generally you define servers either in
>> one place or the other -- if you've done it with "a" in the *Server*
>> buffer, there's no need for it to appear in your config files, too.
>
> Ahh I had not realized that I only needed it in one place, but it
> makes total sense.  Somehow I took the bit of manual I linked above to
> mean I should create the server in the server buffer, then put its
> name in gnus-secondary-select-methods.
>
> So maybe the real bug is just the documentation?

I think so, I'm not aware of any code that is prepared to find a plain
string inside `gnus-secondary-select-methods'. Maybe I'll open a bug for
this just to make sure.

>>>> I have left your other asides aside!
>>> 
>>> No problem.. probably best to post those separately once I find the
>>> right forum.
>>> 
>>>> While this is a fine place to raise general Gnus questions/issues
>>>> (the gnus.general group would be another option),
>>> 
>>> I think you mean 'gmane.emacs.gnus.general'?  It is hard to tell what
>>> information on
>>> 
>>> https://www.gnu.org/software/emacs/manual/html_node/gnus/Gnus-Development.html
>>> 
>>> and
>>> 
>>> https://www.gnus.org/resources.html
>>> 
>>> is up-to-date; some links are clearly dead.
>>> 
>>> Is that newsgroup still bi-directionally gatewayed with ding@gnus.org?
>
>> Yes, sorry, I did mean gmane.emacs.gnus.general, and yes that's still
>> gatewayed to ding@gnus.org. So far as I know there's just
>> gmane.emacs.gnus.general and gmane.emacs.gnus.user. I don't think
>> there's any real difference anymore (probably "general" used to be more
>> for development?) but you do get different people responding in the
>> different groups.
>
> OK great, is there a gatewayed email list for gmane.emacs.gnus.user as
> well?

I don't think so, no.

>>> Is there any way to browse archives on the web?
>
>>> The only reference I could find to reporting bugs is bugs@gnus.org; is
>>> that current?  Is there really no web-based bug tracking system?
>
>> Generally we report bugs from within Emacs, using M-x report-emacs-bug.
>> You can see them online here:
>
>> https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs
>
> Great, thank you.  I'm a bit wary of M-x report-emacs-bug from work as
> I suspect it would run afoul of our security policy.
>
> I spent quite a bit of time last week converting some more low-hanging
> fruit of my xemacs config, and turning off new behaviors that
> disagreed with me, so I've got Emacs in a bit more tolerable state for
> editing.
>
> My biggest concern now with fully transitioning, other than a lot more
> time, is how slow it is over ssh forwarded X11.  As I said xemacs is
> perfectly snappy, but Emacs is taking sometimes 30-60+ sec just to
> create a new frame.
>
> I turned off tooltips which seemed to be causing much of the latency
> issues, then it seemed that toolbars & menubars were the issue because
> after dragging another window over an Emacs frame, everything would
> redraw immediately but the menubars and toolbars, which could again
> take 30-60+ seconds with Emacs being essentially frozen to input.
> Switching gtk to lucid (Debian testing) did not make appreciable
> difference.
>
> I've now noticed that the problem only occurs when a frame of
> an Emacs is dragged over another frame of the same Emacs, so I suspect
> some problem with the event handling loop.  I will submit a bug
> report; this is perfectly reproducible with emacs -Q after ssh'ing
> from my work laptop (on home network) to my work desktop (in office
> 30mi away) and then back to my personal home desktop, even with
> tooltips/tool bars/menu bars/scroll bars off.
>
> And then I'll get back to Gnus..

We'll be here :)