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 2285 invoked from network); 4 Feb 2022 16:12:41 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 4 Feb 2022 16:12:41 -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 1nG1CP-008uvB-KM for ml@inbox.vuxu.org; Fri, 04 Feb 2022 10:12:37 -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 1nG1CP-003veC-4w for ml@inbox.vuxu.org; Fri, 04 Feb 2022 10:12:37 -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 1nG1CN-003ve5-Sd for ding@lists.math.uh.edu; Fri, 04 Feb 2022 10:12:35 -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 1nG1CL-008uux-5n for ding@lists.math.uh.edu; Fri, 04 Feb 2022 10:12:35 -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=FCeqS0PbL2Wo2r43m2qF5HCq90zQE5PuVxKJJNysxzw=; b=CcMa4QUP08HMt7d9RdsHw7uJMf 6npGbIPN8KJSpEC1Shl9+ko1ZbmL66EOkq6vERMTobYhkUJkUUk7kVYCHtYifq46yUWzId7qnVZ62 1H5AMZyQ2KwYHMpH0DGL+wkPwZnHR6t0YDCXevToIS8FdFkO5Bg7HWenSLb8SoFNs3CA=; 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 1nG1CD-0006m0-4v for ding@gnus.org; Fri, 04 Feb 2022 17:12:27 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nG1CB-0005lw-Ah for ding@gnus.org; Fri, 04 Feb 2022 17:12:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: how to kill a virtual group Date: Fri, 04 Feb 2022 08:12:15 -0800 Message-ID: <87leyq8vc0.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> <87v8xziu7t.fsf@ericabrahamsen.net> <87h79j8t3s.fsf@zoho.eu> <87zgnbjr90.fsf@ericabrahamsen.net> <87bkzrz3hg.fsf@zoho.eu> <87k0efjjfb.fsf@ericabrahamsen.net> <875ypzyrmb.fsf@zoho.eu> <877daek1pc.fsf@ericabrahamsen.net> <87r18jl5xi.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:lILfNJWHinvaV7QXqjm2LkxjjcM= List-ID: Precedence: bulk Emanuel Berg writes: > Eric Abrahamsen wrote: > >> I think it would be weird if Gnus let you edit a server >> you'd defined in your .gnus.el file, and then those edits >> were simply overwritten next time you restarted Gnus. > > But then you get the situation now where the same stuff has to > be treated differently ... which should never happen. > > Something like this could be used from .gnus.el and *Server*, > alike since they, while different, should differ on the > interface level only ... > > (defun gnus-edit-server (srv params &optional redefine) > "Create or edit SRV with PARAMS. > If REDEFINE is non-nil, overwrite existing data ..." > ... ) > > If people then choose to ignore that and instead edit the data > directly in .gnus.el then yes, that would reset any in-between > session changes, be it from Lisp or *Server* or any other > thinkable way for that matter - and that's completely fine, it > is that way with everything, and so it should. Set the integer > to something, change it to something else, if it is set again > on the next init that's what it'll be - I mean, what else > would one have it be and how ever would that work? > > So interactive interface from Emacs (buttons etc), interface > from Lisp (Elisp code); they uses the same setters and > functions one level below to do the actual business; and when > done, no worry and no record where the data was set. Well, I understand where you're coming from, but I don't think writing all this code and changing Gnus' behavior is worth it for some conceptual idea of consistency and purity. With proper messaging to the user (and non-buggy code) it's just not a huge tragedy.