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, 18 Jan 2021 13:07:20 -0500 [thread overview]
Message-ID: <874kjejezr.fsf@lwm.klanderman.net> (raw)
In-Reply-To: <87eeivwae3.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Fri, 08 Jan 2021 10:28:52 -0800")
Hi Eric,
Thank you for your reply and sorry for the delay getting back to you..
I ended up spending a lot of time looking into nnmaildir issues the
last few weeks after switching to it, and have now decided that nnml
is probably the better choice despite some warnings below here
https://www.gnu.org/software/emacs/manual/html_node/gnus/Choosing-a-Mail-Back-End.html
and will probably be trying that next.
>>>>> On January 8, 2021 Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> Welcome back!
thank you!
>> In that function, this code (unchanged in 5.13 / Debian testing emacs-gtk):
>>
>> ;; It could be a named method, search all servers
>> (let ((servers gnus-secondary-select-methods))
>> (while (and servers
>> (not (equal server (format "%s:%s" (caar servers)
>> (cadar servers)))))
>> (pop servers))
>> (car servers))
>>
>> is not handling the fact that gnus-secondary-select-methods may
>> contain virtual server name strings (only handling select methods,
>> assuming it can take car/cdr of elements).
> Okay, I'm not 100% parsing the above. I think I understand the
> fundamental issue: on startup, when Gnus is looping over all infos and
> categorizing them by select method, it barfs somehow when checking if an
> info belongs to your nnfolder server, because it somehow can't look up
> the server. Because... it's a string name, not a (list) method?
Almost; because the nnmaildir is a string name.
> I'm not sure. Can you show your complete config for
> `gnus-secondary-select-methods'?
Yes, sorry I should have been more clear; the bug occurs when
gnus-secondary-select-methods is '("mail" (nnfolder ""))
and "mail" is defined in the server buffer as
(nnmaildir "mail"
(directory "~/Gnus/mail")
(get-new-mail t))
When the order is swapped, the bug is avoided.
With "mail" appearing first, when looking up an info belonging to the
nnfolder, it hits the code cited, and barfs on caar and cadar of
servers (the car of servers is "mail").
> I don't think you're supposed to be able to define a server as a
> plain string.
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 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?
Is there any way to browse archives on the web?
I hadn't known the whole history of gmane or even that it was Lars'
project, sorry to hear of all the trouble that caused him, though I
got side-tracked for some time reading a bunch of his blog and was
reminded how enjoyable his writing is..
> if you have a very specific problem or feature request you'd
> like to make, I would recommend just opening a bug report.
> Lars is watching those pretty closely.
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?
> Also, upgrade your Emacs :)
Yeah I know! And there are a huge number of new features, etc..
Unfortunately in my earlier much less time constrained life 20+ years
ago, I built up a huge amount of .emacs customizations (40+ .el files,
16k+ lines), which will take some time to sort thru and convert the
stuff I'm still using, as well as configure a lot of new default
behavior in GNU emacs. But xemacs is generally working fine for me.
I do have a very minimal config for GNU emacs (which I need to use for
slime for work), but to tell you the truth, especially now that I've
been WFH 10+ months over an X-forwarding ssh connection, GNU emacs is
so much slower, it is nearly unusable while xemacs is nearly as good
as being in the office (we cannot have code on work laptop).
Greg
next prev parent reply other threads:[~2021-01-18 18:07 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 [this message]
2021-01-21 23:50 ` Eric Abrahamsen
2021-01-25 17:51 ` Greg Klanderman
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=874kjejezr.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.