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: Thu, 01 Oct 2020 18:13:50 +0200 Message-ID: <1872097e3b35c576672cd126e26d6555@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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5622"; 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 Thu Oct 01 18:20:07 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 1kO1JO-0001Ne-Tt for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Oct 2020 18:20:06 +0200 Original-Received: from localhost ([::1]:46970 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kO1JN-0004aN-RA for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Oct 2020 12:20:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38824) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kO1DR-0005h4-1b for emacs-devel@gnu.org; Thu, 01 Oct 2020 12:13:57 -0400 Original-Received: from smtprelay01.ispgateway.de ([80.67.18.13]:20481) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kO1DO-00013G-F2; Thu, 01 Oct 2020 12:13:56 -0400 Original-Received: from [46.244.222.18] (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 1kO1B7-0005TH-RL; Thu, 01 Oct 2020 18:11:33 +0200 In-Reply-To: <83wo0agl6u.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/01 12:13:51 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:256874 Archived-At: Hello Eli, Eli Zaretskii writes: > [...] >> > For example, one can assign CC Mode to the category "programming >> > languages", then it will be in the same category as perl.el, python.el >> > and fortran.el. >> > [...] >> >> Where does this assignment happen, on the user's local machine or on the >> package repository website (or yet another place?), what semantics are >> associated with that assignment, and how are these semantics exposed to >> the user? > > I don't know. It's the semantics you proposed, so you know what you > had in mind. However, I don't see how that could matter, because the > problem is a fundamental one, and doesn't depend on the semantics of > the category. It seems I'm trying to be too abstract to get things across. Let me try to approach it from the solution space: 1. On the ELPA package repository, a new attribute would be added to the package database. The attribute type would be based on string, with restrictions suited to make the value usable as a filename. For each new package uploaded to ELPA, the author would be encouraged to fill in a value for the new attribute. 2. When a new package is installed locally, the Emacs user would be prompted under which headline or keyword he wants the package's config to be added to the init files. The value of the new ELPA attribute would offered as the default choice at the prompt. 3. With the value chosen by the user in the previous step, Custom would look for a file named ~/.emacs.d/setup-.el, and create it if it doesn't already exist. Custom would then search that file for a section for the new package (using some magic-comment convention as I for instance described in my earlier post). If a section already exists, job done. If no section for the new package exists, Custom would create one, and fill in the default init code for the package (as defined by the package author in the package's documentation). If there is no init code to insert, Custom would just insert an empty magic-comment section for the new package. >From what I understood of your comments, you seem to claim that local users choosing different names in step #2 would cause a problem? Looking forward to your thoughts, --alexander