From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: [NonGNU ELPA] New package: devil Date: Wed, 17 May 2023 14:30:16 +0100 Message-ID: References: <87ttwjbfqq.fsf@gmail.com> <83y1lv5qe9.fsf@gnu.org> <87ednkaeqp.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000fa709205fbe3b072" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7862"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel , Philip Kaludercic To: Susam Pal Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 17 15:31:16 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 1pzHFL-0001rU-Qa for ged-emacs-devel@m.gmane-mx.org; Wed, 17 May 2023 15:31:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pzHEi-0007m0-MZ; Wed, 17 May 2023 09:30:36 -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 1pzHEf-0007lb-UH for emacs-devel@gnu.org; Wed, 17 May 2023 09:30:34 -0400 Original-Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pzHEd-0003d1-UK for emacs-devel@gnu.org; Wed, 17 May 2023 09:30:33 -0400 Original-Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-6ab174bb726so382945a34.1 for ; Wed, 17 May 2023 06:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684330229; x=1686922229; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KckgpzGEqdSERxU++GolGOXSMp52NsEaac+/2/ICTHo=; b=nh06O3HJVt04dUbDEYHanzqIJBZyqLeB6cQG21vfzEcy+0oCjcXuK52scaAVZzo9ye slwM4IQHC5O+maf9or98VpIUHauVrJO8LIMEG5L4DIUkWHtyv99LDZxe+sjATWf7VEMj iDZBJKlqOfb2rk31Iu7OKcq9Js2HJfrBxDEpyrQWnvchIA9STWN+ck1OC8BqslL/617B I0rwZzQXUU5RVp19YODQqXfTw0Y6aoFeQYVss6b/mthLJbpy8ATRYqS1JwXWUNTljCgF 1H2TtgQpdZX3plrRz6GkSdsPFNMn/5OHeUNTK8Do+2Huhdh65ehCrOP3C+p2JA0tozOP 6IVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684330229; x=1686922229; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KckgpzGEqdSERxU++GolGOXSMp52NsEaac+/2/ICTHo=; b=AeMyOAyMm6OogLLX4tv0codDqLlME5+zE+psnu8zVwmw/l2+GolDwJPBLc0tvR036m 8XvedobXtjzPIM5f+C7Tvq4VdIgI7kFUQhzfLMaiAWIVIkbcvAQk968EXlKLwbm2Lnj6 bSCvN26xYfkETC3LHnUx85hGHYKeSDKsY/Tjlg6iCYm9RpwjCwtkLaGDjcJ0YTcjQtZv tuJynHL6vJ0b/jASI36BK5clBOuUDcR3YtFfDdWpIHn4vD5D0jA36zI+Vwmwh8bR/QZf xHZxXyycvz9bQWGoQiI0YnMfwVZuHBM+nUx6b3AT9busVEBR+rfxDLzymiulOteL3VNM J9XA== X-Gm-Message-State: AC+VfDyO8GvRwSg9wmzUWpKaFV9IrtNdd8sYrzY1l5AdRD7fjInutr5A toSP8aRXgnwAxCXb58J08oCX9k77IAZas0kB1gc= X-Google-Smtp-Source: ACHHUZ6AKQqvFbhBVlmma2o7n/k0OcHWsGLpzirH1M2KngccbokV/v394+yYbwFLbLYeQd1SE3/AZWX/5tKbS2FL+98= X-Received: by 2002:aca:2113:0:b0:396:42c7:3c5 with SMTP id 19-20020aca2113000000b0039642c703c5mr746242oiz.57.1684330228902; Wed, 17 May 2023 06:30:28 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::32e; envelope-from=joaotavora@gmail.com; helo=mail-ot1-x32e.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, HTML_MESSAGE=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:306159 Archived-At: --000000000000fa709205fbe3b072 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, May 13, 2023, 10:06 Susam Pal wrote: > Philip Kaludercic wrote: > > > > Jim Porter writes: > > > > > On 5/10/2023 11:33 PM, Eli Zaretskii wrote: > > >> Please reconsider, I think this name is very unfortunate, because it > > >> gives users no clue whatsoever about the package's purpose. > > > > > > How about something like "devil-keys"? That should make it clear that > > > the package has something to do with keys. It doesn't tell exactly > > > what it *does* with those keys, but I think a more-detailed > > > description belongs in the package description or the manual. > > > > > > Within the package itself, I think it would be fine to refer to it as > > > "Devil" (without the "-keys"), since once you're looking at the > > > package in detail, the "keys" hint isn't needed anymore. > > > > I think this is a nice idea, and a good compromise. > > I worry that choosing "devil-keys" as the package identifier is going > to make the identifier inconsistent with how Devil is packaged in > MELPA. The instructions to install Devil are going to become more > complicated than they need to be with differing instructions for MELPA > and NonGNU ELPA. > > I am not convinced that a meaningful name is necessary for this > package. Consider the popular package meow. It is a fairly recent > package that was created in 2020 and added in December 2022. It exists > with the name "meow" in NonGNU ELPA. People who do not know about it > of course do not know about it. But people who do know about it do not > get confused about what it does. I doubt anyone is going to stumble > upon these packages merely due to a meaningful name. At minimum, one > is going to run M-x package-list-packages RET and search the buffer > for strings like "modal", "key", etc. But more typically, people > encounter these packages via recommendations from other community > members. People learn about packages like this in some context where > the context makes it clear what these packages do. > > In general, I do not think packages with quirky names or names > unrelated to the purpose of the package is a problem. On the other > hand, I feel, the more the merrier! At the same time, I do acknowledge > that opinions on this matter differ. > > Devil is a package created as a result of a whimsical idea and I think > the whimsical name is befitting. In my humble opinion, an additional > suffix like "-keys" does not really add much. One still has to read > the package description to understand what it does. However adding > this suffix does take away something. It takes away simplicity, > elegance, and consistency. It introduces inconsistency between the > package identifier and the package name. It introduces inconsistency > between NonGNU ELPA and MELPA. > > I believe that using "devil" as both the package identifier and name, > combined with the updated package description mentioning its purpose > as a key sequence translation package does provide sufficient clarity > for anyone browsing the package list. > > I would like to thank everyone who has generously invested their time > and contributed to this discussion. Despite differing opinions, I > wanted to take a moment to express my thoughts on the matter. > FWIW i agree with you on all points. It's important for packages to be allowed to keep the names the developers baptized them with. Jo=C3=A3o > --000000000000fa709205fbe3b072 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, May 13, 2023, 10:06 Susam Pal <susam.pal@gmail.com> wrote:
Philip Kaludercic <philipk@posteo.net> wrote:<= br> >
> Jim Porter <jporterbugs@gmail.com> writes:
>
> > On 5/10/2023 11:33 PM, Eli Zaretskii wrote:
> >> Please reconsider, I think this name is very unfortunate, bec= ause it
> >> gives users no clue whatsoever about the package's purpos= e.
> >
> > How about something like "devil-keys"? That should make= it clear that
> > the package has something to do with keys. It doesn't tell ex= actly
> > what it *does* with those keys, but I think a more-detailed
> > description belongs in the package description or the manual.
> >
> > Within the package itself, I think it would be fine to refer to i= t as
> > "Devil" (without the "-keys"), since once you= 're looking at the
> > package in detail, the "keys" hint isn't needed any= more.
>
> I think this is a nice idea, and a good compromise.

I worry that choosing "devil-keys" as the package identifier is g= oing
to make the identifier inconsistent with how Devil is packaged in
MELPA. The instructions to install Devil are going to become more
complicated than they need to be with differing instructions for MELPA
and NonGNU ELPA.

I am not convinced that a meaningful name is necessary for this
package. Consider the popular package meow. It is a fairly recent
package that was created in 2020 and added in December 2022. It exists
with the name "meow" in NonGNU ELPA. People who do not know about= it
of course do not know about it. But people who do know about it do not
get confused about what it does. I doubt anyone is going to stumble
upon these packages merely due to a meaningful name. At minimum, one
is going to run M-x package-list-packages RET and search the buffer
for strings like "modal", "key", etc. But more typicall= y, people
encounter these packages via recommendations from other community
members. People learn about packages like this in some context where
the context makes it clear what these packages do.

In general, I do not think packages with quirky names or names
unrelated to the purpose of the package is a problem. On the other
hand, I feel, the more the merrier! At the same time, I do acknowledge
that opinions on this matter differ.

Devil is a package created as a result of a whimsical idea and I think
the whimsical name is befitting. In my humble opinion, an additional
suffix like "-keys" does not really add much. One still has to re= ad
the package description to understand what it does. However adding
this suffix does take away something. It takes away simplicity,
elegance, and consistency. It introduces inconsistency between the
package identifier and the package name. It introduces inconsistency
between NonGNU ELPA and MELPA.

I believe that using "devil" as both the package identifier and n= ame,
combined with the updated package description mentioning its purpose
as a key sequence translation package does provide sufficient clarity
for anyone browsing the package list.

I would like to thank everyone who has generously invested their time
and contributed to this discussion. Despite differing opinions, I
wanted to take a moment to express my thoughts on the matter.

FWIW i agree w= ith you on all points.

I= t's important for packages to be allowed to keep the names the develope= rs baptized them with.=C2=A0

Jo=C3=A3o
--000000000000fa709205fbe3b072--