unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Susam Pal <susam.pal@gmail.com>
To: emacs-devel@gnu.org
Cc: Philip Kaludercic <philipk@posteo.net>
Subject: Re: [NonGNU ELPA] New package: devil
Date: Sat, 13 May 2023 10:05:32 +0100	[thread overview]
Message-ID: <CAK-5M90p-tHwa1sBGWvLTGTU6wY351fVWy300kcFd4QHoYp+UQ@mail.gmail.com> (raw)
In-Reply-To: <87ednkaeqp.fsf@posteo.net>

Philip Kaludercic <philipk@posteo.net> wrote:
>
> 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, 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.



  reply	other threads:[~2023-05-13  9:05 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11  5:23 [NonGNU ELPA] New package: devil Payas Relekar
2023-05-11  6:26 ` Po Lu
2023-05-11  6:33 ` Eli Zaretskii
2023-05-11  6:52   ` Philip Kaludercic
2023-05-11  7:07     ` Eli Zaretskii
2023-05-12 15:02       ` Brian Cully via Emacs development discussions.
2023-05-11  8:09     ` Susam Pal
2023-05-11  8:45       ` Philip Kaludercic
2023-05-11  8:58         ` Eli Zaretskii
2023-05-11  9:08           ` Susam Pal
2023-05-11  9:12             ` Philip Kaludercic
2023-05-11  9:19               ` Susam Pal
2023-05-11  9:34                 ` Ruijie Yu via Emacs development discussions.
2023-05-11 10:09                   ` Susam Pal
2023-05-11 10:31                     ` Susam Pal
2023-05-11 10:36             ` Eli Zaretskii
2023-05-11  8:56       ` Eli Zaretskii
2023-05-12 16:19   ` Jim Porter
2023-05-13  7:10     ` Philip Kaludercic
2023-05-13  9:05       ` Susam Pal [this message]
2023-05-15 22:12         ` Richard Stallman
2023-05-17 13:30         ` João Távora
2023-05-17 14:06           ` Philip Kaludercic
2023-05-17 15:41             ` João Távora
2023-05-17 15:46               ` Eli Zaretskii
2023-05-13 22:30     ` Richard Stallman
2023-05-14  4:29       ` Naming guidelines for ELPA packages (was: Re: [NonGNU ELPA] New package: devil) Jim Porter
2023-05-14  7:47         ` Naming guidelines for ELPA packages Philip Kaludercic
2023-05-14 19:23           ` Jim Porter
2023-05-14 19:33             ` Philip Kaludercic
2023-05-19  3:49               ` Jim Porter
2023-05-19  4:33                 ` Akib Azmain Turja
2023-05-20 16:51                   ` Philip Kaludercic
2023-05-21 21:03                   ` Richard Stallman
2023-05-14 21:36         ` Stefan Monnier via Emacs development discussions.
2023-05-14 22:17           ` Jim Porter
2023-05-14 23:00             ` Stefan Monnier
2023-05-15  1:36               ` Jim Porter
2023-05-15 22:15         ` Naming guidelines for ELPA packages (was: Re: [NonGNU ELPA] New package: devil) Richard Stallman
2023-05-15 22:15         ` Richard Stallman
2023-05-16  4:51           ` Jim Porter
2023-05-16  8:42           ` Naming guidelines for ELPA packages Madhu
  -- strict thread matches above, loose matches on Subject: below --
2023-05-09  1:57 [NonGNU ELPA] New package: devil Susam Pal
2023-05-09  8:42 ` Philip Kaludercic
2023-05-09  8:52   ` Eli Zaretskii
2023-05-09  8:58     ` Philip Kaludercic
2023-05-09 18:19       ` chad
2023-05-09 22:07         ` Susam Pal
2023-05-09 20:56   ` Susam Pal
2023-05-10  6:09     ` Philip Kaludercic
2023-05-10 21:00       ` Susam Pal
2023-05-10 21:56       ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK-5M90p-tHwa1sBGWvLTGTU6wY351fVWy300kcFd4QHoYp+UQ@mail.gmail.com \
    --to=susam.pal@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=philipk@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).