all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Greg Klanderman <gak@klanderman.net>
To: Eric Abrahamsen <eric@ericabrahamsen.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 12:51:04 -0500	[thread overview]
Message-ID: <8735yogb1z.fsf@lwm.klanderman.net> (raw)
In-Reply-To: <875z3p7stg.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Thu, 21 Jan 2021 15:50:51 -0800")

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



  reply	other threads:[~2021-01-25 17:51 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 [this message]
2021-01-25 18:41         ` Eric Abrahamsen
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735yogb1z.fsf@lwm.klanderman.net \
    --to=gak@klanderman.net \
    --cc=emacs-devel@gnu.org \
    --cc=eric@ericabrahamsen.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.