Re: question regarding my emacs package

[Philip Kaludercic]

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

> On Mon, Jun 12, 2023 at 9:45 AM Philip Kaludercic <philipk@posteo.net> wrote:
>>
>> ram via "Emacs development discussions." <emacs-devel@gnu.org> writes:
>>
>> > thanks. did not know this existed. from a quick glance, it looks like
>> > there’s no crossover in prefixes? that seems ok
>>
>> Yes, but it is pretty close and will probably cause confusion.  That
>> being said, João is not part of any ELPA so one could argue the name
>> hasn't been reserved...
>
> Just some thoughts:
>
> 1. There is no name clash, as ram observed

Yes, there is only the potential for confusion.

> 2. I'm not aware of a name reservation/parking procedure.  As far as I can
> tell, ram's breadcrumbs.el isn't a part of any ELPA yet.
>
> 3. If early manifestation of adding a library is somehow relevant
> then I might point you to this ~8-month old thread where I propose we
> add breadcrumb.el to Emacs [1].  That's where breadcrumb.el was born and
> proposed for Emacs.  

Oh, I did not know that.  Intuitively, I would argue that you tried to
reserve the name in the "core emacs/ELPA namespace" first.

>                      I'm still on the fence about whether to propose
> it for a :core package or ELPA package.  It takes inspiration on a
> similar-named lsp-mode feature and the "breadcrumb" concept is apparently
> a common name given to the type of feature breadcrumb.el enables.

I think that both options would be fine, and I'd be happy to help with
either.

> 4. There is no name clash, I think this bears repeating.
>
> 5. Above, I wrote "if early manifestation... is relevant".  I don't think
> it should be.  If avoiding confusion to users is a goal to pursue -- and
> if this confusion is indeed real (see 4 and 1) -- then I think it's more
> important to evaluate the potential consequences of a rename in existing
> users of each package.  We don't know that number, but merely as data point,
> breadcrumbs.el has 6 github stars and breadcrumb.el has 116.

Arguing via stars is difficult, because on the one hand you are a well
known Elisp author and your packages are bound to attract more attention
over a longer period of time, but we cannot deduce anything from these
facts.  E.g. None of my packages (except for Compat, which is
co-maintained) are on GitHub, so this metric couldn't be used if ram
decided to use SourceHut as well.

> 6. Please let's avoid another "meaning of names/meaning of life" thread.
> There is no name clash.

Ok, in that case I won't argue that that this is one of the issue of
using intuitive names ;)

> João
>
> [1]: https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg01027.html

-- 
Philip Kaludercic