From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: A proposal for a friendlier Emacs Date: Thu, 01 Oct 2020 20:23:25 +0300 Message-ID: <83ft6xhnci.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32689"; mail-complaints-to="usenet@ciao.gmane.io" Cc: alexander.adolf@condition-alpha.com, rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 01 19:28:27 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 1kO2NX-0008OP-08 for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Oct 2020 19:28:27 +0200 Original-Received: from localhost ([::1]:33336 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kO2NW-0007ic-1Z for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Oct 2020 13:28:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kO2It-0001HP-TW for emacs-devel@gnu.org; Thu, 01 Oct 2020 13:23:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58308) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kO2It-0003uO-4w; Thu, 01 Oct 2020 13:23:39 -0400 Original-Received: from [176.228.60.248] (port=4439 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kO2Il-0006fA-Un; Thu, 01 Oct 2020 13:23:32 -0400 In-Reply-To: (message from Stefan Monnier on Thu, 01 Oct 2020 12:49:39 -0400) 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:256896 Archived-At: > From: Stefan Monnier > Cc: Alexander Adolf , rms@gnu.org, > emacs-devel@gnu.org > Date: Thu, 01 Oct 2020 12:49:39 -0400 > > >> >From what I understood of your comments, you seem to claim that local > >> users choosing different names in step #2 would cause a problem? > > 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. > > For that there would be tags. That's not the problem, and tags are not the solution. The problem is with the concept of having groups of packages that load together, and whose customizations are on a single .el file. Once a package can belong to more than one such group (and there will be such packages), this concept breaks. Anyway, I've already said this several times, and since it doesn't seem to help drive the point home, I will assume that I'm missing something important here, or am otherwise confused, and will shut up in this thread from now on.