From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Greg Klanderman <gak@klanderman.net>
Cc: emacs-devel@gnu.org
Subject: Re: gnus-server-to-method crash on virtual server name in gnus-secondary-select-methods
Date: Mon, 25 Jan 2021 10:41:36 -0800 [thread overview]
Message-ID: <87zh0w3llr.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <8735yogb1z.fsf@lwm.klanderman.net> (Greg Klanderman's message of "Mon, 25 Jan 2021 12:51:04 -0500")
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 :)
next prev parent reply other threads:[~2021-01-25 18:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 18:14 gnus-server-to-method crash on virtual server name in gnus-secondary-select-methods Greg Klanderman
2021-01-08 18:28 ` Eric Abrahamsen
2021-01-18 18:07 ` Greg Klanderman
2021-01-21 23:50 ` Eric Abrahamsen
2021-01-25 17:51 ` Greg Klanderman
2021-01-25 18:41 ` Eric Abrahamsen [this message]
2021-01-26 19:11 ` Greg Klanderman
2021-01-26 10:51 ` Robert Pluim
2021-01-26 19:09 ` slow X11 frame creation and refresh after occlusion (was: gnus-server-to-method crash on virtual server name in gnus-secondary-select-methods) Greg Klanderman
2021-01-27 8:07 ` slow X11 frame creation and refresh after occlusion Robert Pluim
2021-01-30 19:32 ` Greg Klanderman
2021-02-01 8:56 ` Robert Pluim
2021-02-03 21:52 ` Greg Klanderman
2021-02-04 8:24 ` Robert Pluim
2021-02-04 21:14 ` Greg Klanderman
2021-02-05 9:53 ` Robert Pluim
2021-02-05 17:12 ` Greg Klanderman
2021-01-30 22:21 ` Greg Klanderman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zh0w3llr.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=emacs-devel@gnu.org \
--cc=gak@klanderman.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).