From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: ding@gnus.org
Subject: Re: how to kill a virtual group
Date: Mon, 31 Jan 2022 11:24:54 -0800 [thread overview]
Message-ID: <87v8xziu7t.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <87ee4oc0qy.fsf@zoho.eu>
Emanuel Berg <moasenwood@zoho.eu> writes:
> Eric Abrahamsen wrote:
>
>> Because the two kinds of server need to be treated
>> separately. Gnus is not allowed to overwrite your gnus.el
>> file, so if you want to make a change to a server defined
>> there, Gnus can't do it via the *Server* buffer: you have to
>> shut Gnus down, edit gnus.el, and restart. Conversely,
>> servers defined via the *Server* buffer are saved in
>> .newsrc.eld, which only Gnus is supposed to touch, so edits
>> should be made via the *Server* buffer. Gnus needs to know
>> which servers are which.
>
> In general, stuff that are the same, it shouldn't matter where
> or in what manner they are defined.
In principle I agree, but in this case I think it's pretty useful to
have the ability to define servers in a config file, that's maybe
version controlled, but then also have the ability to create and destroy
servers on the fly within Gnus.
> If they are not the same, then if something should or
> shouldn't happen to them because of that, they should have
> something so one can check - if they by accident look the
> same, add some flag or something to the data
> structure perhaps?
In this case, I think the check is *supposed* to be whether the server
is present in `gnus-(secondary-)select-method(s)', or whether it is
present in `gnus-server-alist'.
In theory it's a clean way to do it, because the first two variables are
simply loaded from your .gnus.el and never modified, and the second
variable is loaded from and saved to .newsrc.el by Gnus, which is
allowed to modify the variable. It's just that something seems to not be
working correctly there.
next prev parent reply other threads:[~2022-01-31 19:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-28 15:07 Uwe Brauer
2022-01-28 17:05 ` Eric Abrahamsen
2022-01-28 21:02 ` Uwe Brauer
2022-01-28 22:21 ` Eric Abrahamsen
2022-01-29 0:03 ` Emanuel Berg
2022-01-29 4:18 ` Eric Abrahamsen
2022-01-29 15:48 ` Emanuel Berg
2022-01-29 17:17 ` Eric Abrahamsen
2022-01-30 22:33 ` Emanuel Berg
2022-01-31 19:24 ` Eric Abrahamsen [this message]
2022-01-31 21:59 ` Emanuel Berg
2022-02-01 1:43 ` Eric Abrahamsen
2022-02-01 3:10 ` Emanuel Berg
2022-02-01 4:32 ` Eric Abrahamsen
2022-02-01 7:26 ` Emanuel Berg
2022-02-01 16:10 ` Eric Abrahamsen
2022-02-04 2:30 ` Emanuel Berg
2022-02-04 16:12 ` Eric Abrahamsen
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=87v8xziu7t.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=ding@gnus.org \
/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.
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 NNTP newsgroup(s).