From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Adolf Newsgroups: gmane.emacs.devel Subject: Re: A proposal for a friendlier Emacs Date: Fri, 02 Oct 2020 18:10:22 +0200 Message-ID: <5fc45e0421ce68e13a37b924f9860dfb@condition-alpha.com> References: <4be18b5f-dc07-2703-a2de-1ed08916ebdf@gmail.com> <1e340d941b6fd0b21a477f39fc935468@condition-alpha.com> <62ff80b8ff943b698ef8c46849b8bc50@condition-alpha.com> <83y2l0vas0.fsf@gnu.org> <83lfgyrn57.fsf@gnu.org> <83h7rlsxpw.fsf@gnu.org> <0e3f9f50238be8a62b481f78c1d26c83@condition-alpha.com> <83d024jxex.fsf@gnu.org> <83wo0agl6u.fsf@gnu.org> <1872097e3b35c576672cd126e26d6555@condition-alpha.com> <83imbthqdg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21398"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 02 18:12:13 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kONfJ-0005TO-11 for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Oct 2020 18:12:13 +0200 Original-Received: from localhost ([::1]:48778 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kONfI-00064v-1h for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Oct 2020 12:12:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54486) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kONde-0004k2-Jc for emacs-devel@gnu.org; Fri, 02 Oct 2020 12:10:31 -0400 Original-Received: from smtprelay01.ispgateway.de ([80.67.18.13]:49447) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kONdc-0000Ug-Cj; Fri, 02 Oct 2020 12:10:30 -0400 Original-Received: from [46.244.220.37] (helo=condition-alpha.com) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kONbH-0004bB-EA; Fri, 02 Oct 2020 18:08:03 +0200 In-Reply-To: <83imbthqdg.fsf@gnu.org> X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=80.67.18.13; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay01.ispgateway.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/02 12:10:24 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:256949 Archived-At: Eli Zaretskii writes: > [...] > No. The problem I have in mind is that the user might decide to give > a package some keyword when first installed, but then the user might > wish to have the same package in another setup-KEYWORD.el file as > well, because it is useful as part of another group of packages. In that case, my idea would be that the user manually moves the block of init code for the package in question (including magic comments) from setup-A.el to setup-B.el. I did _not_ have in mind that the user would be assigning any new information (such as e.g. tags or categories) to the packages. My mental model was that the packages "live" on ELPA, and are read-only as far the Emacs user is concerned (as is the status-quo today). In my model, the only purpose in life for the new attribute was to give the init code block a default, initial place to store, and to allow the user to override that place at package installation time. As time goes by, and things evolve, the user is of course free to rename init files, move config blocks between them, create new init files and move existing blocks there, etc. For as long as the magic comments are retained (maybe there's a better way than magic comments even), Custom would be able to find stuff, maintain the (custom-set-*) blocks, and things would go smoothly. Cheers, --alexander