Re: [NonGNU ELPA] New package: devil

Re: [NonGNU ELPA] New package: devil

[Payas Relekar]

Richard Stallman <rms@gnu.org> writes:

> Why use the name "Devil" for this?  It doesn't seen to explain anything
> about the package's purpose.  It is likely to put some people off.

Every name is going to put someone or another off, can't really help it.
OpenBSD has their daemon and there are already funny anecdotes about it,
but it doesn't hurt anyone.

> If there is no clear reason why "Devil" is a good name, let's choose
> a better name now.

As mentioned by Susam in previous mail, as well as the repo README, the
name refers both to 'eVil' (extensible Vi Layer) as well as 'God-mode'.

The name is distinct, and I like it for what it is.
--

Re: [NonGNU ELPA] New package: devil

[Po Lu]

Payas Relekar <relekarpayas@gmail.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Why use the name "Devil" for this?  It doesn't seen to explain anything
>> about the package's purpose.  It is likely to put some people off.
>
> Every name is going to put someone or another off, can't really help it.
> OpenBSD has their daemon and there are already funny anecdotes about it,
> but it doesn't hurt anyone.
>
>> If there is no clear reason why "Devil" is a good name, let's choose
>> a better name now.
>
> As mentioned by Susam in previous mail, as well as the repo README, the
> name refers both to 'eVil' (extensible Vi Layer) as well as 'God-mode'.
>
> The name is distinct, and I like it for what it is.

What the package does is not obvious from its name.  That's the main
problem with it.

Re: [NonGNU ELPA] New package: devil

[Eli Zaretskii]

> From: Payas Relekar <relekarpayas@gmail.com>
> Cc: Philip Kaludercic <philipk@posteo.net>,  susam.pal@gmail.com,
>  emacs-devel@gnu.org
> Date: Thu, 11 May 2023 10:53:15 +0530
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > Why use the name "Devil" for this?  It doesn't seen to explain anything
> > about the package's purpose.  It is likely to put some people off.
> 
> Every name is going to put someone or another off, can't really help it.
> OpenBSD has their daemon and there are already funny anecdotes about it,
> but it doesn't hurt anyone.

"daemon" is a term whose meaning in computing context is widely
accepted for many years.  "Devil' isn't.

> > If there is no clear reason why "Devil" is a good name, let's choose
> > a better name now.
> 
> As mentioned by Susam in previous mail, as well as the repo README, the
> name refers both to 'eVil' (extensible Vi Layer) as well as 'God-mode'.

People are extremely unlikely to understand that, even if they know
about Evil in Emacs.  And even if they do figure out this is related
to Evil, the truth is that the package is not meant to be used by
users of Evil.

> The name is distinct, and I like it for what it is.

Please reconsider, I think this name is very unfortunate, because it
gives users no clue whatsoever about the package's purpose.

Thanks.

Re: [NonGNU ELPA] New package: devil

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Payas Relekar <relekarpayas@gmail.com>
>> Cc: Philip Kaludercic <philipk@posteo.net>,  susam.pal@gmail.com,
>>  emacs-devel@gnu.org
>> Date: Thu, 11 May 2023 10:53:15 +0530
>> 
>> Richard Stallman <rms@gnu.org> writes:
>> 
>> > Why use the name "Devil" for this?  It doesn't seen to explain anything
>> > about the package's purpose.  It is likely to put some people off.
>> 
>> Every name is going to put someone or another off, can't really help it.
>> OpenBSD has their daemon and there are already funny anecdotes about it,
>> but it doesn't hurt anyone.

Also, "daemon" is not just an OpenBSD thing.

> "daemon" is a term whose meaning in computing context is widely
> accepted for many years.  "Devil' isn't.

I agree.

>> > If there is no clear reason why "Devil" is a good name, let's choose
>> > a better name now.
>> 
>> As mentioned by Susam in previous mail, as well as the repo README, the
>> name refers both to 'eVil' (extensible Vi Layer) as well as 'God-mode'.
>
> People are extremely unlikely to understand that, even if they know
> about Evil in Emacs.  And even if they do figure out this is related
> to Evil, the truth is that the package is not meant to be used by
> users of Evil.

I think it is more likely than you assume if you ask enthusiasts, but if
we consider the average user who doesn't hang around in Emacs-related
forums, chats, etc. then this is very true.

>> The name is distinct, and I like it for what it is.
>
> Please reconsider, I think this name is very unfortunate, because it
> gives users no clue whatsoever about the package's purpose.

Susam, what do you say?  Do you have any ideas?  A few names I can think
of might be:

- no-modifier-mode
- prefixless-mode
- implicit-ctrl-mode
- comma->control-mode

but I'm not really convinced by any of these (haven't really used the
package yet either).  Perhaps this might inspire someone else to come up
with a better suggestion?

If you really insist, then I think we really have to come up with a
better description, because "Minor mode for Devil-like command entering"
is really confusing.

> Thanks.

Re: [NonGNU ELPA] New package: devil

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Payas Relekar <relekarpayas@gmail.com>,  rms@gnu.org,
>   susam.pal@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 11 May 2023 06:52:18 +0000
> 
> Susam, what do you say?  Do you have any ideas?  A few names I can think
> of might be:
> 
> - no-modifier-mode
> - prefixless-mode
> - implicit-ctrl-mode
> - comma->control-mode

How about comma-modifiers ?

> If you really insist, then I think we really have to come up with a
> better description, because "Minor mode for Devil-like command entering"
> is really confusing.

Agreed.

Re: [NonGNU ELPA] New package: devil

[Brian Cully via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

> How about comma-modifiers ?

Or maybe ‘com-mode’.

I'll see myself out.

-bjc

Re: [NonGNU ELPA] New package: devil

[Susam Pal]

Philip Kaludercic <philipk@posteo.net> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Payas Relekar <relekarpayas@gmail.com>
> >> Cc: Philip Kaludercic <philipk@posteo.net>,  susam.pal@gmail.com,
> >>  emacs-devel@gnu.org
> >> Date: Thu, 11 May 2023 10:53:15 +0530
> >>
> >> Richard Stallman <rms@gnu.org> writes:
> >>
> >> > Why use the name "Devil" for this?  It doesn't seen to explain anything
> >> > about the package's purpose.  It is likely to put some people off.
> >>
> >> Every name is going to put someone or another off, can't really help it.
> >> OpenBSD has their daemon and there are already funny anecdotes about it,
> >> but it doesn't hurt anyone.
>
> Also, "daemon" is not just an OpenBSD thing.
>
> > "daemon" is a term whose meaning in computing context is widely
> > accepted for many years.  "Devil' isn't.
>
> I agree.
>
> >> > If there is no clear reason why "Devil" is a good name, let's choose
> >> > a better name now.
> >>
> >> As mentioned by Susam in previous mail, as well as the repo README, the
> >> name refers both to 'eVil' (extensible Vi Layer) as well as 'God-mode'.
> >
> > People are extremely unlikely to understand that, even if they know
> > about Evil in Emacs.  And even if they do figure out this is related
> > to Evil, the truth is that the package is not meant to be used by
> > users of Evil.
>
> I think it is more likely than you assume if you ask enthusiasts, but if
> we consider the average user who doesn't hang around in Emacs-related
> forums, chats, etc. then this is very true.
>
> >> The name is distinct, and I like it for what it is.
> >
> > Please reconsider, I think this name is very unfortunate, because it
> > gives users no clue whatsoever about the package's purpose.
>
> Susam, what do you say?  Do you have any ideas?  A few names I can think
> of might be:
>
> - no-modifier-mode
> - prefixless-mode
> - implicit-ctrl-mode
> - comma->control-mode
>
> but I'm not really convinced by any of these (haven't really used the
> package yet either).  Perhaps this might inspire someone else to come up
> with a better suggestion?

Although the default translation rules in Devil translates comma to
ctrl, m to meta, etc., Devil is very configurable and one is free to
configure Devil in other ways that may or may not involve the comma
key or the modifier keys.

For example, I am aware that there are users of Devil who use the
semicolon as the Devil activation key and translate semicolon to
control. There are also users who only translate some activation key
to control key but regular alt modifier key on their keyboard for the
meta modifier.

> If you really insist, then I think we really have to come up with a
> better description, because "Minor mode for Devil-like command entering"
> is really confusing.
>
> > Thanks.

While I understand the desire for a more descriptive name, I believe
that "Devil" is a suitable choice due to its humorous reference to
both God mode and Evil mode. Some people like the name. Some do not. I
like this name.

If it is essential for the package's name to reflect its purpose, I
propose "Devil" to stand for "Devil's Extremely Versatile Interception
Layer".

I agree that the current description of the package needs improvement.
I have now updated it to "Minor mode for intercepting and translating
key sequences."

Regards,
Susam

Re: [NonGNU ELPA] New package: devil

[Philip Kaludercic]

Susam Pal <susam.pal@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Payas Relekar <relekarpayas@gmail.com>
>> >> Cc: Philip Kaludercic <philipk@posteo.net>,  susam.pal@gmail.com,
>> >>  emacs-devel@gnu.org
>> >> Date: Thu, 11 May 2023 10:53:15 +0530
>> >>
>> >> Richard Stallman <rms@gnu.org> writes:
>> >>
>> >> > Why use the name "Devil" for this?  It doesn't seen to explain anything
>> >> > about the package's purpose.  It is likely to put some people off.
>> >>
>> >> Every name is going to put someone or another off, can't really help it.
>> >> OpenBSD has their daemon and there are already funny anecdotes about it,
>> >> but it doesn't hurt anyone.
>>
>> Also, "daemon" is not just an OpenBSD thing.
>>
>> > "daemon" is a term whose meaning in computing context is widely
>> > accepted for many years.  "Devil' isn't.
>>
>> I agree.
>>
>> >> > If there is no clear reason why "Devil" is a good name, let's choose
>> >> > a better name now.
>> >>
>> >> As mentioned by Susam in previous mail, as well as the repo README, the
>> >> name refers both to 'eVil' (extensible Vi Layer) as well as 'God-mode'.
>> >
>> > People are extremely unlikely to understand that, even if they know
>> > about Evil in Emacs.  And even if they do figure out this is related
>> > to Evil, the truth is that the package is not meant to be used by
>> > users of Evil.
>>
>> I think it is more likely than you assume if you ask enthusiasts, but if
>> we consider the average user who doesn't hang around in Emacs-related
>> forums, chats, etc. then this is very true.
>>
>> >> The name is distinct, and I like it for what it is.
>> >
>> > Please reconsider, I think this name is very unfortunate, because it
>> > gives users no clue whatsoever about the package's purpose.
>>
>> Susam, what do you say?  Do you have any ideas?  A few names I can think
>> of might be:
>>
>> - no-modifier-mode
>> - prefixless-mode
>> - implicit-ctrl-mode
>> - comma->control-mode
>>
>> but I'm not really convinced by any of these (haven't really used the
>> package yet either).  Perhaps this might inspire someone else to come up
>> with a better suggestion?
>
> Although the default translation rules in Devil translates comma to
> ctrl, m to meta, etc., Devil is very configurable and one is free to
> configure Devil in other ways that may or may not involve the comma
> key or the modifier keys.

Right, that was why I said I wasn't convinced by the suggestions with
"comma" in the name.  By the way, you should add a custom setter to the
user option that configures the key to update the minor-mode map to
rebind the key.

> For example, I am aware that there are users of Devil who use the
> semicolon as the Devil activation key and translate semicolon to
> control. There are also users who only translate some activation key
> to control key but regular alt modifier key on their keyboard for the
> meta modifier.
>
>> If you really insist, then I think we really have to come up with a
>> better description, because "Minor mode for Devil-like command entering"
>> is really confusing.
>>
>> > Thanks.
>
> While I understand the desire for a more descriptive name, I believe
> that "Devil" is a suitable choice due to its humorous reference to
> both God mode and Evil mode. Some people like the name. Some do not. I
> like this name.

If you insist, I guess we'll go with that (unless anyone wants to veto
it), but I think it is sad to contribute to the further spread of
confusing and opaque names for packages that has been increasing on GNU
and NonGNU ELPA recently.

> If it is essential for the package's name to reflect its purpose, I
> propose "Devil" to stand for "Devil's Extremely Versatile Interception
> Layer".

I think you know that that is not what is being talked about here.
Retroactive acronyms are usually just a joke, and don't help address the
issue that newcomers face when they are given packages names like
"Corfu", "Captain", "Luwak" or "Eglot".  They are not indicative of
their functionality and at best have vague links to other terminology
that you can make sense of if someone explains it to you (sort of like
the devil to evil/god mode in your case), but most non-enthusiasts
wouldn't see.

While I get the intended pun, and I think "devil-mode" is a clever idea
knowing the context, I would still like to urge you to reconsider -- not
for your own sake but for that of the users.

> I agree that the current description of the package needs improvement.
> I have now updated it to "Minor mode for intercepting and translating
> key sequences."

That probably as good as it gets for a brief description.

> Regards,
> Susam

Re: [NonGNU ELPA] New package: devil

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Payas Relekar <relekarpayas@gmail.com>,
>   rms@gnu.org,  emacs-devel@gnu.org
> Date: Thu, 11 May 2023 08:45:40 +0000
> 
> > I have now updated it to "Minor mode for intercepting and translating
> > key sequences."
> 
> That probably as good as it gets for a brief description.

Except that I'm not sure "intercepting" is correct here.  Is it?

Re: [NonGNU ELPA] New package: devil

[Susam Pal]

Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Philip Kaludercic <philipk@posteo.net>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  Payas Relekar <relekarpayas@gmail.com>,
> >   rms@gnu.org,  emacs-devel@gnu.org
> > Date: Thu, 11 May 2023 08:45:40 +0000
> >
> > > I have now updated it to "Minor mode for intercepting and translating
> > > key sequences."
> >
> > That probably as good as it gets for a brief description.
>
> Except that I'm not sure "intercepting" is correct here.  Is it?

Is the following description better?

"Minor mode for reading and translating key sequences."

Re: [NonGNU ELPA] New package: devil

[Philip Kaludercic]

Susam Pal <susam.pal@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > From: Philip Kaludercic <philipk@posteo.net>
>> > Cc: Eli Zaretskii <eliz@gnu.org>,  Payas Relekar <relekarpayas@gmail.com>,
>> >   rms@gnu.org,  emacs-devel@gnu.org
>> > Date: Thu, 11 May 2023 08:45:40 +0000
>> >
>> > > I have now updated it to "Minor mode for intercepting and translating
>> > > key sequences."
>> >
>> > That probably as good as it gets for a brief description.
>>
>> Except that I'm not sure "intercepting" is correct here.  Is it?
>
> Is the following description better?
>
> "Minor mode for reading and translating key sequences."
                  ^
                  is this redundant?  hard to translate without reading.

That sounds very generic, is the package capable of doing that for any
kind of key translation.

Re: [NonGNU ELPA] New package: devil

[Susam Pal]

Philip Kaludercic <philipk@posteo.net> wrote:
>
> Susam Pal <susam.pal@gmail.com> writes:
>
> > Eli Zaretskii <eliz@gnu.org> wrote:
> >>
> >> > From: Philip Kaludercic <philipk@posteo.net>
> >> > Cc: Eli Zaretskii <eliz@gnu.org>,  Payas Relekar <relekarpayas@gmail.com>,
> >> >   rms@gnu.org,  emacs-devel@gnu.org
> >> > Date: Thu, 11 May 2023 08:45:40 +0000
> >> >
> >> > > I have now updated it to "Minor mode for intercepting and translating
> >> > > key sequences."
> >> >
> >> > That probably as good as it gets for a brief description.
> >>
> >> Except that I'm not sure "intercepting" is correct here.  Is it?
> >
> > Is the following description better?
> >
> > "Minor mode for reading and translating key sequences."
>                   ^
>                   is this redundant?  hard to translate without reading.
>
> That sounds very generic, is the package capable of doing that for any
> kind of key translation.

Thanks for the feedback. In that case,

"Minor mode for translating key sequences."

Re: [NonGNU ELPA] New package: devil

[Ruijie Yu via Emacs development discussions.]

Susam Pal <susam.pal@gmail.com> writes:

>> > "Minor mode for reading and translating key sequences."
>>                   ^
>>                   is this redundant?  hard to translate without reading.
>>
>> That sounds very generic, is the package capable of doing that for any
>> kind of key translation.
>
> Thanks for the feedback. In that case,
>
> "Minor mode for translating key sequences."

Can your package translate more than just modifier keys like control or
meta?  Like translate key sequence "j k" into something else?

If the answer is no, then maybe you should clarify that in the
description.

-- 
Best,


RY

Re: [NonGNU ELPA] New package: devil

[Susam Pal]

Ruijie Yu <ruijie@netyu.xyz> wrote:
>
>
> Susam Pal <susam.pal@gmail.com> writes:
>
> >> > "Minor mode for reading and translating key sequences."
> >>                   ^
> >>                   is this redundant?  hard to translate without reading.
> >>
> >> That sounds very generic, is the package capable of doing that for any
> >> kind of key translation.
> >
> > Thanks for the feedback. In that case,
> >
> > "Minor mode for translating key sequences."
>
> Can your package translate more than just modifier keys like control or
> meta?  Like translate key sequence "j k" into something else?
>
> If the answer is no, then maybe you should clarify that in the
> description.

Yes, this is possible. Although the defaults cater to how I and some
other users use this package, i.e., converting comma-prefixed key
sequences with modifier-based key sequences, the key sequence
translation logic does not make any assumption about modifier keys.

For example, one could configure the following key translations:

(setq devil-key "j")
(require 'devil)
(global-devil-mode)
(setq devil-logging t)
(setq devil-translations '(("%k k" . "RET")
                           ("%k l" . "<f10>")
                           ("%k m" . "C-M-")))

Assuming vanilla Emacs key bindings have not been altered, now typing
"j j" results in a newline. Typing "j l" opens the menu bar.
Similarly, typing "j m s" results in regexp i-search.

Regards,
Susam

Re: [NonGNU ELPA] New package: devil

[Susam Pal]

On Thu, 11 May 2023 at 11:09, Susam Pal <susam.pal@gmail.com> wrote:
>
> Ruijie Yu <ruijie@netyu.xyz> wrote:
> >
> >
> > Susam Pal <susam.pal@gmail.com> writes:
> >
> > >> > "Minor mode for reading and translating key sequences."
> > >>                   ^
> > >>                   is this redundant?  hard to translate without reading.
> > >>
> > >> That sounds very generic, is the package capable of doing that for any
> > >> kind of key translation.
> > >
> > > Thanks for the feedback. In that case,
> > >
> > > "Minor mode for translating key sequences."
> >
> > Can your package translate more than just modifier keys like control or
> > meta?  Like translate key sequence "j k" into something else?
> >
> > If the answer is no, then maybe you should clarify that in the
> > description.
>
> Yes, this is possible. Although the defaults cater to how I and some
> other users use this package, i.e., converting comma-prefixed key
> sequences with modifier-based key sequences, the key sequence
> translation logic does not make any assumption about modifier keys.
>
> For example, one could configure the following key translations:
>
> (setq devil-key "j")
> (require 'devil)
> (global-devil-mode)
> (setq devil-logging t)
> (setq devil-translations '(("%k k" . "RET")
>                            ("%k l" . "<f10>")
>                            ("%k m" . "C-M-")))
>
> Assuming vanilla Emacs key bindings have not been altered, now typing
> "j j" results in a newline. Typing "j l" opens the menu bar.
> Similarly, typing "j m s" results in regexp i-search.

Correction.

(setq devil-key "j")
(require 'devil)
(global-devil-mode)
(setq devil-translations '(("%k k" . "RET")
                           ("%k l" . "<f10>")
                           ("%k m" . "C-M-")))

Now "j k" inserts newline, "j l" opens menu bar, and "j m s" performs
regexp i-search.

On Thu, 11 May 2023 at 11:09, Susam Pal <susam.pal@gmail.com> wrote:
>
> Ruijie Yu <ruijie@netyu.xyz> wrote:
> >
> >
> > Susam Pal <susam.pal@gmail.com> writes:
> >
> > >> > "Minor mode for reading and translating key sequences."
> > >>                   ^
> > >>                   is this redundant?  hard to translate without reading.
> > >>
> > >> That sounds very generic, is the package capable of doing that for any
> > >> kind of key translation.
> > >
> > > Thanks for the feedback. In that case,
> > >
> > > "Minor mode for translating key sequences."
> >
> > Can your package translate more than just modifier keys like control or
> > meta?  Like translate key sequence "j k" into something else?
> >
> > If the answer is no, then maybe you should clarify that in the
> > description.
>
> Yes, this is possible. Although the defaults cater to how I and some
> other users use this package, i.e., converting comma-prefixed key
> sequences with modifier-based key sequences, the key sequence
> translation logic does not make any assumption about modifier keys.
>
> For example, one could configure the following key translations:
>
> (setq devil-key "j")
> (require 'devil)
> (global-devil-mode)
> (setq devil-logging t)
> (setq devil-translations '(("%k k" . "RET")
>                            ("%k l" . "<f10>")
>                            ("%k m" . "C-M-")))
>
> Assuming vanilla Emacs key bindings have not been altered, now typing
> "j j" results in a newline. Typing "j l" opens the menu bar.
> Similarly, typing "j m s" results in regexp i-search.

Re: [NonGNU ELPA] New package: devil

[Eli Zaretskii]

> From: Susam Pal <susam.pal@gmail.com>
> Date: Thu, 11 May 2023 10:08:50 +0100
> Cc: Philip Kaludercic <philipk@posteo.net>, relekarpayas@gmail.com, rms@gnu.org, 
> 	emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Except that I'm not sure "intercepting" is correct here.  Is it?
> 
> Is the following description better?
> 
> "Minor mode for reading and translating key sequences."

I'd drop the "reading" part as well.  It should be clear that in order
to translate a sequence, you need to read it.

Re: [NonGNU ELPA] New package: devil

[Eli Zaretskii]

> From: Susam Pal <susam.pal@gmail.com>
> Date: Thu, 11 May 2023 09:09:34 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Payas Relekar <relekarpayas@gmail.com>,
>  rms@gnu.org, emacs-devel@gnu.org
> 
> > - no-modifier-mode
> > - prefixless-mode
> > - implicit-ctrl-mode
> > - comma->control-mode
> >
> > but I'm not really convinced by any of these (haven't really used the
> > package yet either).  Perhaps this might inspire someone else to come up
> > with a better suggestion?
> 
> Although the default translation rules in Devil translates comma to
> ctrl, m to meta, etc., Devil is very configurable and one is free to
> configure Devil in other ways that may or may not involve the comma
> key or the modifier keys.

Then how about key-transl or something similar?

Re: [NonGNU ELPA] New package: devil

[Jim Porter]

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.

Re: [NonGNU ELPA] New package: devil

[Philip Kaludercic]

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.

Re: [NonGNU ELPA] New package: devil

[Susam Pal]

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.

Re: [NonGNU ELPA] New package: devil

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I worry that choosing "devil-keys" as the package identifier is going
  > to make the identifier inconsistent with how Devil is packaged in
  > MELPA.

Compatibility with MELPA is not one of our goals.  It is not a reason
to choose a suboptimal way of doing things.

  > 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.

That's what generally happens with a package whose name gives no
guide: people who regularly use the package know what it does, and
others have no idea.

The reason to choose a name that tells something about the package is
to get a better outcome than that.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [NonGNU ELPA] New package: devil

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]

On Sat, May 13, 2023, 10:06 Susam Pal <susam.pal@gmail.com> wrote:

> 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.
>

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ão

>

[-- Attachment #2: Type: text/html, Size: 4567 bytes --]

Re: [NonGNU ELPA] New package: devil

[Philip Kaludercic]

João Távora <joaotavora@gmail.com> writes:

> 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.

Important in what sense?  There have frequently been authors that have
changed the names of their packages when this was suggested to them, so
it doesn't like it was important for them.  People are making a bigger
deal out of quirky names than it should be.

Re: [NonGNU ELPA] New package: devil

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

On Wed, May 17, 2023 at 3:06 PM Philip Kaludercic <philipk@posteo.net>
wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > 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.
>
> Important in what sense?

In just the sense Susam described.  My message simply intended to support
Susam's view.

> There have frequently been authors that have
> changed the names of their packages when this was suggested to them, so
> it doesn't like it was important for them.

I don't see the relevance. Susam doesn't want to and IMO it's perfectly
legitimate.

> People are making a bigger
> deal out of quirky names than it should be.

Precisely my point, so let's stop insisting that authors change the names
of their creations.

[-- Attachment #2: Type: text/html, Size: 1200 bytes --]

Re: [NonGNU ELPA] New package: devil

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 17 May 2023 16:41:58 +0100
> Cc: Susam Pal <susam.pal@gmail.com>, emacs-devel <emacs-devel@gnu.org>
> 
> let's stop insisting that authors change the names
> of their creations.

We are not insisting.  We are respectfully asking them to consider the
possibility, and explain why it will be useful.

Re: [NonGNU ELPA] New package: devil

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

I like this way of serving both goals at once: a clue about what the job is,
and a name to distinguish this package from others for thatjob.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Naming guidelines for ELPA packages (was: Re: [NonGNU ELPA] New package: devil)

[Jim Porter]

On 5/13/2023 3:30 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>    > 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.
> 
> I like this way of serving both goals at once: a clue about what the job is,
> and a name to distinguish this package from others for thatjob.
> 

Maybe we could turn this into a general guideline, and document it 
somewhere on GNU ELPA (maybe the README). Something like the below? It 
could probably use some editorial work, but I thought an example "story" 
of choosing a package name might help explain things to readers.

----------------------------------------

Naming is hard. To assist package authors, here are some guidelines for 
choosing good Emacs package names. Package names should be:

   * Memorable: Aim for short, distinct names that users can easily recall.
   * Intuitive: Names don't need to fully describe a package, but they 
should at least provide a hint about what the package does.

For example, suppose I've written a package that provides an interface 
between GObjects and Emacs Lisp, and named it "goeli". This isn't a very 
good name, since it's not easy to remember (users may find themselves 
asking, "Wait... was it 'goli' or 'goeli'?"), and it's nearly impossible 
to guess what it does from the name.

After thinking about it some more, I have a flash of insight: I'll call 
it "goblin" (for _GOb_ject _L_isp _In_terface)! This is easy enough to 
remember, but it's still not intuitive.

Perhaps the best name for a package like this would simply be "gobject". 
That's both memorable *and* intuitive.

However, after thinking about it yet again, I find myself disappointed: 
while "gobject" is a thoroughly practical name, it's just not very fun. 
Instead, I finally opt for a compromise: I'll still use "Goblin" when 
documenting the package and prefix names in my code with "goblin-", but 
I decide to submit it to GNU ELPA as "goblin-functions". While this 
isn't as descriptive as "gobject", it does at least provide a hint to 
the reader that this is a collection of functions (intended for other 
Lisp authors, as opposed to end users).

Re: Naming guidelines for ELPA packages

[Philip Kaludercic]

Jim Porter <jporterbugs@gmail.com> writes:

> On 5/13/2023 3:30 PM, Richard Stallman wrote:
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>    > 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.
>> I like this way of serving both goals at once: a clue about what the
>> job is,
>> and a name to distinguish this package from others for thatjob.
>> 
>
> Maybe we could turn this into a general guideline, and document it
> somewhere on GNU ELPA (maybe the README). Something like the below? It
> could probably use some editorial work, but I thought an example
> "story" of choosing a package name might help explain things to
> readers.

I've suggested something like this in the past, but I can't find my
message.  Either way, I think this is a good idea that could help avoid
a lot of bikeshedding.

> ----------------------------------------
>
> Naming is hard. To assist package authors, here are some guidelines
> for choosing good Emacs package names. Package names should be:
>
>   * Memorable: Aim for short, distinct names that users can easily recall.
>   * Intuitive: Names don't need to fully describe a package, but they
>     should at least provide a hint about what the package does.
>
> For example, suppose I've written a package that provides an interface
> between GObjects and Emacs Lisp, and named it "goeli". This isn't a
> very good name, since it's not easy to remember (users may find
> themselves asking, "Wait... was it 'goli' or 'goeli'?"), and it's
> nearly impossible to guess what it does from the name.
>
> After thinking about it some more, I have a flash of insight: I'll
> call it "goblin" (for _GOb_ject _L_isp _In_terface)! This is easy
> enough to remember, but it's still not intuitive.
>
> Perhaps the best name for a package like this would simply be
> "gobject". That's both memorable *and* intuitive.
>
> However, after thinking about it yet again, I find myself
> disappointed: while "gobject" is a thoroughly practical name, it's
> just not very fun. Instead, I finally opt for a compromise: I'll still
> use "Goblin" when documenting the package and prefix names in my code
> with "goblin-", but I decide to submit it to GNU ELPA as
> "goblin-functions". While this isn't as descriptive as "gobject", it
> does at least provide a hint to the reader that this is a collection
> of functions (intended for other Lisp authors, as opposed to end
> users).


I agree with everything up until the last paragraph, but am not
convinced that encouraging a "fun name" should be part of the
guidelines.

Re: Naming guidelines for ELPA packages

[Jim Porter]

On 5/14/2023 12:47 AM, Philip Kaludercic wrote:
> I agree with everything up until the last paragraph, but am not
> convinced that encouraging a "fun name" should be part of the
> guidelines.

I think I need to adjust the passage a bit to emphasize that the 
Emacs/ELPA maintainers would *prefer* a simple and straightforward name 
like "gobject". However, I also think it's important to show how you can 
come up with a good compromise if you're a package author who just can't 
let go of your fun package name. In my mind, showing in the 
documentation how to compromise on this would go a long way towards 
making package authors not feel like they're being micromanaged.

Re: Naming guidelines for ELPA packages

[Philip Kaludercic]

Jim Porter <jporterbugs@gmail.com> writes:

> On 5/14/2023 12:47 AM, Philip Kaludercic wrote:
>> I agree with everything up until the last paragraph, but am not
>> convinced that encouraging a "fun name" should be part of the
>> guidelines.
>
> I think I need to adjust the passage a bit to emphasize that the
> Emacs/ELPA maintainers would *prefer* a simple and straightforward
> name like "gobject". However, I also think it's important to show how
> you can come up with a good compromise if you're a package author who
> just can't let go of your fun package name. In my mind, showing in the
> documentation how to compromise on this would go a long way towards
> making package authors not feel like they're being micromanaged.

That would sound acceptable to me.

Re: Naming guidelines for ELPA packages

[Jim Porter]

On 5/14/2023 12:33 PM, Philip Kaludercic wrote:
> Jim Porter <jporterbugs@gmail.com> writes:
> 
>> I think I need to adjust the passage a bit to emphasize that the
>> Emacs/ELPA maintainers would *prefer* a simple and straightforward
>> name like "gobject". ...
> 
> That would sound acceptable to me.

Ok, how about something like the following? I just expanded it a bit to 
provide more context and adjusted the wording slightly here and there 
(for example, these are now "recommendations" instead of "guidelines").

----------------------------------------

Naming is hard. However, taking some time to choose a good name for your 
package will help make your package easier to find and to use. To assist 
package authors, here are some recommendations for choosing good Emacs 
package names. Package names should be:

   * Memorable: Aim for short, distinct names that users can easily recall.
   * Intuitive: Names don't need to fully describe a package, but they 
should at least provide a hint about what the package does.

For example, suppose I've written a package that provides an interface 
between GObjects and Emacs Lisp, and named it "goeli". This isn't a very 
good name, since it's not easy to remember (users may find themselves 
asking, "Wait... was it 'goli' or 'goeli'?"), and it's nearly impossible 
to guess what it does from the name.

After thinking about it some more, I have a flash of insight: I'll call 
it "goblin" (for _GOb_ject _L_isp _In_terface)! This is easy enough to 
remember, but it's still not intuitive.

Perhaps the best name for a package like this would simply be "gobject". 
That's both memorable *and* intuitive, not to mention being as 
straightforward as you can get. If possible, the ELPA maintainers 
recommend that you choose a name like this.

However, suppose that at this point, I find myself disappointed: while 
"gobject" is a thoroughly practical name, I just don't want to give up 
the name "goblin". Instead, I could opt for a compromise: I'll still use 
"Goblin" when documenting the package and prefix names in my code with 
"goblin-", but I decide to submit it to GNU ELPA as "goblin-gobject". 
While this isn't as concise as "gobject", it does let the user know 
right away that this package has something to do with GObjects.

Re: Naming guidelines for ELPA packages

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 2829 bytes --]

Jim Porter <jporterbugs@gmail.com> writes:

> On 5/14/2023 12:33 PM, Philip Kaludercic wrote:
>> Jim Porter <jporterbugs@gmail.com> writes:
>> 
>>> I think I need to adjust the passage a bit to emphasize that the
>>> Emacs/ELPA maintainers would *prefer* a simple and straightforward
>>> name like "gobject". ...
>> That would sound acceptable to me.
>
> Ok, how about something like the following? I just expanded it a bit
> to provide more context and adjusted the wording slightly here and
> there (for example, these are now "recommendations" instead of
> "guidelines").
>
> ----------------------------------------
>
> Naming is hard. However, taking some time to choose a good name for
> your package will help make your package easier to find and to use. To
> assist package authors, here are some recommendations for choosing
> good Emacs package names. Package names should be:
>
>   * Memorable: Aim for short, distinct names that users can easily recall.
>   * Intuitive: Names don't need to fully describe a package, but they
>     should at least provide a hint about what the package does.
>
> For example, suppose I've written a package that provides an interface
> between GObjects and Emacs Lisp, and named it "goeli". This isn't a
> very good name, since it's not easy to remember (users may find
> themselves asking, "Wait... was it 'goli' or 'goeli'?"), and it's
> nearly impossible to guess what it does from the name.
>
> After thinking about it some more, I have a flash of insight: I'll
> call it "goblin" (for _GOb_ject _L_isp _In_terface)! This is easy
> enough to remember, but it's still not intuitive.
>
> Perhaps the best name for a package like this would simply be
> "gobject". That's both memorable *and* intuitive, not to mention being
> as straightforward as you can get. If possible, the ELPA maintainers
> recommend that you choose a name like this.
>
> However, suppose that at this point, I find myself disappointed: while
> "gobject" is a thoroughly practical name, I just don't want to give up
> the name "goblin". Instead, I could opt for a compromise: I'll still
> use "Goblin" when documenting the package and prefix names in my code
> with "goblin-", but I decide to submit it to GNU ELPA as
> "goblin-gobject". While this isn't as concise as "gobject", it does
> let the user know right away that this package has something to do
> with GObjects.
>

The example name you suggested, "gobject", is indeed a good name, but
there's a little problem that if someone ever comes up with a better
package, it won't find any name for itself.

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Naming guidelines for ELPA packages

[Philip Kaludercic]

Akib Azmain Turja <akib@disroot.org> writes:

> Jim Porter <jporterbugs@gmail.com> writes:
>
>> On 5/14/2023 12:33 PM, Philip Kaludercic wrote:
>>> Jim Porter <jporterbugs@gmail.com> writes:
>>> 
>>>> I think I need to adjust the passage a bit to emphasize that the
>>>> Emacs/ELPA maintainers would *prefer* a simple and straightforward
>>>> name like "gobject". ...
>>> That would sound acceptable to me.
>>
>> Ok, how about something like the following? I just expanded it a bit
>> to provide more context and adjusted the wording slightly here and
>> there (for example, these are now "recommendations" instead of
>> "guidelines").
>>
>> ----------------------------------------
>>
>> Naming is hard. However, taking some time to choose a good name for
>> your package will help make your package easier to find and to use. To
>> assist package authors, here are some recommendations for choosing
>> good Emacs package names. Package names should be:
>>
>>   * Memorable: Aim for short, distinct names that users can easily recall.
>>   * Intuitive: Names don't need to fully describe a package, but they
>>     should at least provide a hint about what the package does.
>>
>> For example, suppose I've written a package that provides an interface
>> between GObjects and Emacs Lisp, and named it "goeli". This isn't a
>> very good name, since it's not easy to remember (users may find
>> themselves asking, "Wait... was it 'goli' or 'goeli'?"), and it's
>> nearly impossible to guess what it does from the name.
>>
>> After thinking about it some more, I have a flash of insight: I'll
>> call it "goblin" (for _GOb_ject _L_isp _In_terface)! This is easy
>> enough to remember, but it's still not intuitive.
>>
>> Perhaps the best name for a package like this would simply be
>> "gobject". That's both memorable *and* intuitive, not to mention being
>> as straightforward as you can get. If possible, the ELPA maintainers
>> recommend that you choose a name like this.
>>
>> However, suppose that at this point, I find myself disappointed: while
>> "gobject" is a thoroughly practical name, I just don't want to give up
>> the name "goblin". Instead, I could opt for a compromise: I'll still
>> use "Goblin" when documenting the package and prefix names in my code
>> with "goblin-", but I decide to submit it to GNU ELPA as
>> "goblin-gobject". While this isn't as concise as "gobject", it does
>> let the user know right away that this package has something to do
>> with GObjects.
>>
>
> The example name you suggested, "gobject", is indeed a good name, but
> there's a little problem that if someone ever comes up with a better
> package, it won't find any name for itself.

One could argue this would help preventing NIH and encouraging people to
contribute to existing projects.

Re: Naming guidelines for ELPA packages

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The example name you suggested, "gobject", is indeed a good name, but
  > there's a little problem that if someone ever comes up with a better
  > package, it won't find any name for itself.

I think there will be no great difficulty.  It could be `gobject-2'
or `gobj-susan' or many other things that would be somewhat good.

So I think Philip's recommendations are good.

  > One could argue this would help preventing NIH and encouraging people to
  >  contribute to existing projects.

If it has a little such effect, that could be beneficial.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Naming guidelines for ELPA packages

[Stefan Monnier via Emacs development discussions.]

> Naming is hard.  To assist package authors, here are some guidelines for
> choosing good Emacs package names.  Package names should be:
>
>   * Memorable: Aim for short, distinct names that users can easily recall.
>   * Intuitive: Names don't need to fully describe a package, but they should
>    at least provide a hint about what the package does.

I can go along guidelines to *help* maintainers choose good
package names.  But I think it's very important that we refrain from
*imposing* it on maintainers.

So if the author prefers to stick with `devil`, then that's what it'll
be.  We have much more important things to worry about when it comes to
imposing guidelines (e.g. making sure that the package doesn't overstep
its namespace).


        Stefan

Re: Naming guidelines for ELPA packages

[Jim Porter]

On 5/14/2023 2:36 PM, Stefan Monnier via Emacs development discussions. 
wrote:
>> Naming is hard.  To assist package authors, here are some guidelines for
>> choosing good Emacs package names.  Package names should be:
>>
>>    * Memorable: Aim for short, distinct names that users can easily recall.
>>    * Intuitive: Names don't need to fully describe a package, but they should
>>     at least provide a hint about what the package does.
> 
> I can go along guidelines to *help* maintainers choose good
> package names.  But I think it's very important that we refrain from
> *imposing* it on maintainers.
> 
> So if the author prefers to stick with `devil`, then that's what it'll
> be.  We have much more important things to worry about when it comes to
> imposing guidelines (e.g. making sure that the package doesn't overstep
> its namespace).

I agree. This is mainly an attempt to help package maintainers pick good 
(or "good enough") names on their own so that there's less time spent 
discussing this issue, and also to be upfront about what the Emacs/ELPA 
maintainers would prefer. That way, as a package maintainer, you can 
take these guidelines into account (or not) before you even submit the 
package.

Re: Naming guidelines for ELPA packages

[Stefan Monnier]

> I agree. This is mainly an attempt to help package maintainers pick good (or
> "good enough") names on their own so that there's less time spent discussing
> this issue, and also to be upfront about what the Emacs/ELPA maintainers
> would prefer. That way, as a package maintainer, you can take these
> guidelines into account (or not) before you even submit the package.

Great.  Is there still something that needs to be resolved before we can
add this package to NonGNU ELPA, then?
[ BTW, I wish this went into GNU ELPA, instead.  Oh, and it should have
  a `.gitignore` along the lines of what I put in the appended patch.  ]


        Stefan


diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000000..af7e30dd09
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+/devil-autoloads.el
+/devil-pkg.el
+*.elc

Re: Naming guidelines for ELPA packages

[Jim Porter]

On 5/14/2023 4:00 PM, Stefan Monnier wrote:
>> I agree. This is mainly an attempt to help package maintainers pick good (or
>> "good enough") names on their own so that there's less time spent discussing
>> this issue, and also to be upfront about what the Emacs/ELPA maintainers
>> would prefer. That way, as a package maintainer, you can take these
>> guidelines into account (or not) before you even submit the package.
> 
> Great.  Is there still something that needs to be resolved before we can
> add this package to NonGNU ELPA, then?

In my opinion, no. I only suggested 'devil-keys' as a compromise that 
could address the concerns people had about the name 'devil' not 
providing a hint about what the package does. (In this subthread, I 
mainly wanted to discuss whether we could come up with a general 
guideline to assist package authors in coming up with reasonably-good 
names.)

But then I'm not exactly an authority figure on what does and doesn't go 
into ELPA. :)

Re: Naming guidelines for ELPA packages (was: Re: [NonGNU ELPA] New package: devil)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think your guideline draft is good.  It's a readable policy, and
written very clearly too.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Naming guidelines for ELPA packages (was: Re: [NonGNU ELPA] New package: devil)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think your guideline text is good.  It's quite clear, and readable
too.

But I'm confusd by this subsequent comment:

  > However, I also think it's important to show how you can 
  > come up with a good compromise if you're a package author who just can't 
  > let go of your fun package name. In my mind, showing in the 
  > documentation how to compromise on this would go a long way towards 
  > making package authors not feel like they're being micromanaged.

The last paragraph of your draft text, about goblin-functions,

  > Instead, I finally opt for a compromise: I'll still use "Goblin" when 
  > documenting the package and prefix names in my code with "goblin-", but 
  > I decide to submit it to GNU ELPA as "goblin-functions". While this 
  > isn't as descriptive as "gobject", it does at least provide a hint to 
  > the reader that this is a collection of functions (intended for other 
  > Lisp authors, as opposed to end users).

seems to do that -- so why is a change needed?

I think goblin-gobjects might be a superior compromise.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Naming guidelines for ELPA packages (was: Re: [NonGNU ELPA] New package: devil)

[Jim Porter]

On 5/15/2023 3:15 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> I think your guideline text is good.  It's quite clear, and readable
> too.
> 
> But I'm confusd by this subsequent comment:
> 
>    > However, I also think it's important to show how you can
>    > come up with a good compromise if you're a package author who just can't
>    > let go of your fun package name. In my mind, showing in the
>    > documentation how to compromise on this would go a long way towards
>    > making package authors not feel like they're being micromanaged.
> 
> The last paragraph of your draft text, about goblin-functions,
> 
>    > Instead, I finally opt for a compromise: I'll still use "Goblin" when
>    > documenting the package and prefix names in my code with "goblin-", but
>    > I decide to submit it to GNU ELPA as "goblin-functions". While this
>    > isn't as descriptive as "gobject", it does at least provide a hint to
>    > the reader that this is a collection of functions (intended for other
>    > Lisp authors, as opposed to end users).
> 
> seems to do that -- so why is a change needed?

I just want to adjust the emphasis of the text to gently nudge package 
maintainers to choose something as simple as possible like "gobject" if 
they can (or if they're willing). I think the final draft will be pretty 
close to how it is now, but with a couple extra sentences to add more 
detail.

> I think goblin-gobjects might be a superior compromise.

That's a good idea. I'll change the text to use that name instead. Thanks.

Re: Naming guidelines for ELPA packages

[Madhu]

* Richard Stallman <E1pygTK-0004et-1U @fencepost.gnu.org> :
Wrote on Mon, 15 May 2023 18:15:14 -0400:

> The last paragraph of your draft text, about goblin-functions,
>
>   > Instead, I finally opt for a compromise: I'll still use "Goblin"
>   > when documenting the package and prefix names in my code with
>   > "goblin-", but I decide to submit it to GNU ELPA as
>   > "goblin-functions". While this isn't as descriptive as "gobject",
>   > it does at least provide a hint to the reader that this is a
>   > collection of functions (intended for other Lisp authors, as
>   > opposed to end users).
>
> seems to do that -- so why is a change needed?
>
> I think goblin-gobjects might be a superior compromise.

In case you missed it, goblin-mode was the Oxford Dictionaries word of
the year for 2022, in what seems to rigged elections and an exercise of
social media engineering

https://apnews.com/article/europe-oxford-e1ce91a4c56588c5ece25353cbe52810

	LONDON (AP) — Asked to sum up 2022 in a word, the public has
	chosen a phrase.

	It defines the term as “a type of behavior which is
	unapologetically self-indulgent, lazy, slovenly, or greedy,
	typically in a way that rejects social norms or expectations.”

	First seen on Twitter in 2009, “goblin mode” gained popularity
	in 2022 as people around the world emerged uncertainly from
	pandemic lockdowns.

	“Given the year we’ve just experienced, ‘goblin mode’ resonates
	with all of us who are feeling a little overwhelmed at this
	point,” said Oxford Languages President Casper Grathwohl.

Re: Naming guidelines for ELPA packages

[Drew Adams]

> I can go along guidelines to *help* maintainers choose good
> package names.  But I think it's very important that we refrain from
> *imposing* it on maintainers.
> 
> So if the author prefers to stick with `devil`, then that's what it'll
> be.  We have much more important things to worry about when it comes to
> imposing guidelines (e.g. making sure that the package doesn't overstep
> its namespace).

This.

Let users know the rationale behind the guideline,
in particular that it can help people find/discover
their package.  The same idea is behind the Elisp
libraries that are part of Emacs (modulo hysterical
raisins etc.)