From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: plz -> curl? Date: Mon, 16 May 2022 21:13:51 -0500 Message-ID: References: <874k1vzyom.fsf@posteo.net> <104ffa6b-12ae-53df-e289-aba7d7200654@alphapapa.net> <87o7zxnfsg.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a39ed105df2bb1f4" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19013"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , Philip Kaludercic , mardani29@yahoo.es, emacs-devel To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 17 04:15:17 2022 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 1nqmk0-0004rR-Si for ged-emacs-devel@m.gmane-mx.org; Tue, 17 May 2022 04:15:16 +0200 Original-Received: from localhost ([::1]:42102 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nqmjz-00053O-M9 for ged-emacs-devel@m.gmane-mx.org; Mon, 16 May 2022 22:15:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51222) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nqmir-0003Mh-PR for emacs-devel@gnu.org; Mon, 16 May 2022 22:14:05 -0400 Original-Received: from mail-wm1-f51.google.com ([209.85.128.51]:38705) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nqmip-0008EW-Bx; Mon, 16 May 2022 22:14:05 -0400 Original-Received: by mail-wm1-f51.google.com with SMTP id 1-20020a05600c248100b00393fbf11a05so569542wms.3; Mon, 16 May 2022 19:14:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=woR43BOAsDdOjqnXfcia95g2U5GRoLgUe8oi7CCt5ME=; b=SyjC2YN5GrJQrKb18VFXFnFLXqjkiaLnV9sdtXK9vgYfLiiNOiY5k1/zD8uyBiX5rk VkVw/pNjy16p0rXukUwR+AC5i+HytymFdp9UCdAy6nwaCZESrtGSLFCDWCMTzMTLNCQ6 gF3muE3g4GKLkk+XS8hpir7Amd8hzfhgebb9FRPv4JEcZfRx9z4nVJd1Q6WD2zowgsPU pQXj2ppUDWaLAGUxWSrveaEXOa7bpyPpDrSc8LAdL80o/hihI5Z4H4Iq9hpL3BXNOtiB v2TVYHV+ZOLYPk310Qmgra6NlAu7vCeXDvbuOzUKQfUOSLu04d/BlNQkDoPbHQMRM0S7 c4Tw== X-Gm-Message-State: AOAM530KRHvtgBuNbxu8noQH5X/r4Tdg6PHye9NBjBGLBv9bDSi2pp8j oC48MG1dYIpj0Bjfc/wAmbRXRkQntOEe/AGiPeY= X-Google-Smtp-Source: ABdhPJxxkYSwzofj7lAFUTMuC6Ec2I7iyh0hGkX4aXB0vgoQgmyoTNoforphmR/bM1fEdDfscYAC+f8QkinKQ3IXdnI= X-Received: by 2002:a7b:c017:0:b0:394:5631:62bc with SMTP id c23-20020a7bc017000000b00394563162bcmr30286178wmb.190.1652753640429; Mon, 16 May 2022 19:14:00 -0700 (PDT) In-Reply-To: <87o7zxnfsg.fsf@yahoo.com> Received-SPF: pass client-ip=209.85.128.51; envelope-from=alphadeltapapa@gmail.com; helo=mail-wm1-f51.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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" Xref: news.gmane.io gmane.emacs.devel:289823 Archived-At: --000000000000a39ed105df2bb1f4 Content-Type: text/plain; charset="UTF-8" On Mon, May 16, 2022, 19:50 Po Lu wrote: > Richard Stallman writes: > > > We have arrived at a deep and fundamental disagreement about what it > > means to make a program clear. I have pointed out that the name "plz" > > gives no information about what the package does. It is totally > > unhelpful. > > > > You contend that an arbitrary and unhelpful name is just as good as a > > helpful name. No, that is not my contention at all. I tried to explain my position as clearly as I could in my last messages. The argument is that we have commands to do searches > > from the name to its purpose and from words in its purpose to the > > name. > > > > Those commands are helpful, but using them is laborious by comparison > > woth the simple verbalconnection. > > > > For the packages feature, I am a beginner. I don't know those > > commands. I will learn these commands if I start using packages more, > > but there will always be many users who are beginners in this. > Users who don't know how to use the package system will not be installing the package in the first place. > > > Whenever we add a new package, we should consider whether to change > > its name first. But plz has not been installed for long. Giving it a > > clear, meaningful name now won't cause any pain. > > I agree completely. There are many unhelpful package names, such as > "corfu", "cape", "eglot", "marginalia" and "mcd". At least eglot could > be renamed "lsp-client", which tells the user exactly what it does. > Those packages have distinctive identities to those who use them. Giving them generic names does not help the user remember them; it has the opposite effect. > > > A clear meaningful name does not have to be long. Someone suggested > > `curl' -- meaningful, and quite short. As I said, I don't want to use that name, because it implies more comprehensive support for curl than I intend to provide in the library. As well, there are other packages that provide a front end to curl. Perhaps `curl-url' would be > > even more helpful, to the many who who don't use curl -- and it is > > still short. > Thanks, but no. > If no one has a better idea, let's rename it that way now. > > curl is already taken. `curl-url' would work, but so would > `curl-http-client', which I think is relatively more meaningful. > As I've said, long, purely descriptive package names like that are less useful in the long run, as well as simply being too long. At this time, I don't intend to rename the library. Were it to be proposed for merging into core someday, that would be different--but as has been said, that won't be the case anytime soon, if ever. > --000000000000a39ed105df2bb1f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 16, 2022, 19:50 Po Lu <luangruo@yahoo.com> wrote:
Richard Stallman <rms@gnu.org> writes:

> We have arrived at a deep and fundamental disagreement about what it > means to make a program clear.=C2=A0 I have pointed out that the name = "plz"
> gives no information about what the package does.=C2=A0 It is totally<= br> > unhelpful.
>
> You contend that an arbitrary and unhelpful name is just as good as a<= br> > helpful name.=C2=A0

No, that is not my contention at all. I tried to expla= in my position as clearly as I could in my last messages.=C2=A0

The argument is that we have commands to do searches=
> from the name to its purpose and from words in its purpose to the
> name.
>
> Those commands are helpful, but using them is laborious by comparison<= br> > woth the simple verbalconnection.
>
> For the packages feature, I am a beginner.=C2=A0 I don't know thos= e
> commands.=C2=A0 I will learn these commands if I start using packages = more,
> but there will always be many users who are beginners in this.

Users wh= o don't know how to use the package system will not be installing the p= ackage in the first place.

>
> Whenever we add a new package, we should consider whether to change > its name first.=C2=A0 But plz has not been installed for long.=C2=A0 G= iving it a
> clear, meaningful name now won't cause any pain.

I agree completely.=C2=A0 There are many unhelpful package names, such as "corfu", "cape", "eglot", "marginalia&qu= ot; and "mcd".=C2=A0 At least eglot could
be renamed "lsp-client", which tells the user exactly what it doe= s.

Those packages have distinctive identities to those who use them. Giving = them generic names does not help the user remember them; it has the opposit= e effect.=C2=A0

> A clear meaningful name does not have to be long.=C2=A0 Someone sugges= ted
> `curl' -- meaningful, and quite short.=C2=A0

As I said, I don't wan= t to use that name, because it implies more comprehensive support for curl = than I intend to provide in the library.=C2=A0 As well, there are other pac= kages that provide a front end to curl.=C2=A0

Perhaps `curl-url' would be
> even more helpful, to the many who who don't use curl -- and it is=
> still short.

<= div dir=3D"auto">Thanks, but no.

> If no one has a better idea, let's rename it that way now.

curl is already taken.=C2=A0 `curl-url' would work, but so would
`curl-http-client', which I think is relatively more meaningful.

As I= 9;ve said, long, purely descriptive package names like that are less useful= in the long run, as well as simply being too long.
=
At this time, I don't intend to rename the = library.=C2=A0 Were it to be proposed for merging into core someday, that w= ould be different--but as has been said, that won't be the case anytime= soon, if ever.=C2=A0
--000000000000a39ed105df2bb1f4--