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 32019 invoked from network); 4 Feb 2022 02:30:46 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 4 Feb 2022 02:30:46 -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 1nFoN1-008Ww3-IS for ml@inbox.vuxu.org; Thu, 03 Feb 2022 20:30:43 -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 1nFoN0-003uNF-Pj for ml@inbox.vuxu.org; Thu, 03 Feb 2022 20:30:42 -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 1nFoMy-003uN6-EK for ding@lists.math.uh.edu; Thu, 03 Feb 2022 20:30:40 -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 1nFoMv-008Wvi-EL for ding@lists.math.uh.edu; Thu, 03 Feb 2022 20:30:40 -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=NtJUp+TaNmMVkp5gBJ2y+eYspHb0TyRAIoJDytJkrJ4=; b=hgsdIwWTge/jkP1WSdgZO1qdqj Z1nmSxptxfV3CGbfDqKyBWOvvPAcv/RpyllkJM5c8X6KOJKQzIjLzFIf0h3Xhfm/lJcsGhy3zG6YA PtVAHSuj7X7Y4O++skfg+sWJqb2XUDy93RmsoAkoMj/ZlILAqoglMf7l9geEHeJIQ16g=; 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 1nFoMm-00083e-Fs for ding@gnus.org; Fri, 04 Feb 2022 03:30:32 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nFoMk-00077Y-8Y for ding@gnus.org; Fri, 04 Feb 2022 03:30:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org To: ding@gnus.org From: Emanuel Berg Subject: Re: how to kill a virtual group Date: Fri, 04 Feb 2022 03:30:17 +0100 Message-ID: <87r18jl5xi.fsf@zoho.eu> 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> 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:l4hubknDEPJgJLHrWg6gfw99WxY= Mail-Copies-To: never List-ID: Precedence: bulk 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. -- underground experts united https://dataswamp.org/~incal