From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15577 invoked from network); 31 Jan 2022 19:25:18 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 31 Jan 2022 19:25:18 -0000 Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nEcId-006E9A-5p for ml@inbox.vuxu.org; Mon, 31 Jan 2022 13:25:15 -0600 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94.2) (envelope-from ) id 1nEcIc-003kWD-FN for ml@inbox.vuxu.org; Mon, 31 Jan 2022 13:25:14 -0600 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1nEcIb-003kW6-Bh for ding@lists.math.uh.edu; Mon, 31 Jan 2022 13:25:13 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nEcIZ-006E8q-03 for ding@lists.math.uh.edu; Mon, 31 Jan 2022 13:25:12 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:Mime-Version:References:Message-ID:Date:Subject: From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=8XPR2V3FVVkA8CecaGMbhYVgpcazxFhbkt7518VgJgI=; b=oAOpPqPoudwnfgZ+wbGN3UjS2K x8t1nqoEyY9UoV5u/GUC4hJpcKat/QrpSdt6914poTDfRC3pbg30fytn2cVbF6JdMUZQTGZ+mGwWF tInwRwrYNsH1ukZak/1DxEglRe4myKbWXA7SMowNQi0OsoENK56pyypKihRL8cAmUfRE=; Received: from ciao.gmane.io ([116.202.254.214]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nEcIR-0005vB-GC for ding@gnus.org; Mon, 31 Jan 2022 20:25:06 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nEcIP-00010r-Nr for ding@gnus.org; Mon, 31 Jan 2022 20:25:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: how to kill a virtual group Date: Mon, 31 Jan 2022 11:24:54 -0800 Message-ID: <87v8xziu7t.fsf@ericabrahamsen.net> References: <87a6ffx5jg.fsf@mat.ucm.es> <874k5nokor.fsf@ericabrahamsen.net> <87r18ro9py.fsf@mat.ucm.es> <87czkbmrgf.fsf@ericabrahamsen.net> <87ee4rflwa.fsf@zoho.eu> <87fsp7kwdp.fsf@ericabrahamsen.net> <871r0qtuen.fsf@zoho.eu> <877dailawi.fsf@ericabrahamsen.net> <87ee4oc0qy.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cancel-Lock: sha1:whtt1a1KMCtABMYH//RS8eT3SxI= List-ID: Precedence: bulk Emanuel Berg 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.