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

[Greg Klanderman <gak@klanderman.net>]

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

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

thank you,
Greg