From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.devel Subject: Re: Names are not descriptions; descriptions are not names Date: Fri, 12 May 2023 09:33:41 -0700 Message-ID: References: <3b4a24a3-2d12-16d3-d905-7794ed4269b1@alphapapa.net> <835y8y3sq1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33158"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii , Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 12 18:34:27 2023 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 1pxVis-0008Sv-Cz for ged-emacs-devel@m.gmane-mx.org; Fri, 12 May 2023 18:34:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pxViE-0000fX-OK; Fri, 12 May 2023 12:33:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pxViC-0000fK-Rd for emacs-devel@gnu.org; Fri, 12 May 2023 12:33:44 -0400 Original-Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pxViB-0001vZ-9F; Fri, 12 May 2023 12:33:44 -0400 Original-Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-643a6f993a7so6273529b3a.1; Fri, 12 May 2023 09:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683909221; x=1686501221; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=MaebqQSAT6pbR8uDmW+v8Is0xr5tF1sgsSQ2ydrE/sk=; b=MbHNtkxXNS0ydzl3n7/Aapsrdp/VUoDNJ2BF1PS8HFH2sASlf3jGlJDu0INyqVMHUC x9+kSPPbedhbYKHboccKKZTQY42bDv+JKGH3lODi3VRHcD6MMIzO4Hn0eeXRb6gTru8b 5iJK4bRhdi77e3sZaJIwji/I+I7CLCo5uZB8U0zZ3aUYaeVd9LdWZm2/WsQucyDDMq8A THG/VglD7czsYfrh27HqbnDsn48Hw9KTO8/dlt8tECTbmQKc71Et0/osOOLgTV5ON3F1 +X90/zsp33ZTgmC0K0s2pjsCTlnQSwQpduXML2M0tqxk9gDI+CDhDXh7w2mX++VT7kpD d3Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683909221; x=1686501221; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MaebqQSAT6pbR8uDmW+v8Is0xr5tF1sgsSQ2ydrE/sk=; b=YxSVebhHIcx3Ta/zPgCj8TFciA9ysEj2IaKeooNC4RhGhdCKgp5+ajRQ5FX1IEnPh7 ZeCTk3z6BMzJUL0iIM/CicIfA+bUbUbrwEMAzHeupp2S9jmRsvflFYz3xnDXs6zmZq3Y SiL3WX2ryrmFqibLZA52MKf0XnFiY8JZzL4NkCRKpB1Wt/SmXeCzClgPnQaugjjd2sb6 5Ab4R1HOvzWcycOf9+vqABjtNeusFiZvFeNysg5af0TZ9KqxD2nbTtsXLR/i3alM5uMu hcgejiNVzDWtavji9yQ94PweuU63+Fb5GQCt+dLfICX8zqIwyMmNbMRWq4sQNvKIFCrw mBCQ== X-Gm-Message-State: AC+VfDzjhUnI0Taj+F0S/pXszTuMICr+2GiPksMIXntYdpzSMtDiMZxL BPRWTkANWe7oVmqJK5SzfCh8uSMYS4E= X-Google-Smtp-Source: ACHHUZ5dq/HbaKSjOG77j8iYoW47JXj5oUQe77NGXwMum7aMqYdWfEpPWFO6xdJb+Nvob/K79es7IQ== X-Received: by 2002:a05:6a00:14d3:b0:642:e61d:b2c9 with SMTP id w19-20020a056a0014d300b00642e61db2c9mr35181048pfu.11.1683909221424; Fri, 12 May 2023 09:33:41 -0700 (PDT) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id n14-20020a62e50e000000b0064399be15f0sm7266913pff.183.2023.05.12.09.33.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 May 2023 09:33:41 -0700 (PDT) Content-Language: en-US In-Reply-To: <835y8y3sq1.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::42f; envelope-from=jporterbugs@gmail.com; helo=mail-pf1-x42f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306092 Archived-At: On 5/12/2023 12:37 AM, Eli Zaretskii wrote: > Again, there's no requirement to allow users distinguishing between > similar packages just by looking at the name. That can only be done > by reading the package's description. > > IOW, the name should allow some kind of initial filtering: if I'm not > interested in key translation, I don't need to look further at a > package named key-transl. It's the same first-order filtering we > apply to email by just looking at the Subject. Nothing more, nothing > less. Looking at the list of packages in GNU ELPA, almost all of them have a description well within the limits of what we'd expect from an email Subject. To use your example of "42", while that alone would be cryptic, a Subject like "42: The answer to life, the universe, and everything" would be ok, I think. That being said, are there places we can make package descriptions more visible? Both "M-x list-packages" and the ELPA package list on the web show the descriptions prominently, so I find them both to be very easy to find packages, even if they have cryptic names. However, there may be further improvements we should make in this area. Packages can have keywords, so improving those might help, or maybe we could add metadata for broad package categories (e.g. "theme", "key bindings", "major mode", etc)... Still, there's room for a light touch with improving package names (especially if we let the actual package *identifier* be a slight variation on the name). For example, the Devil package could otherwise stay the same, but we could give it a package identifier of "devil-keys". The functions and commands would still just be "devil-FOO", and the documentation could still say "devil" instead of "devil-keys" (except when talking about how to install the package, of course). Would that be a reasonable compromise for cases like this?