Re: Help sought understanding shorthands wrt modules/packages

[Dmitry Gutov <dgutov@yandex.ru>]

On 12.11.2022 20:45, João Távora wrote:

> I've tried to explain my original plan again.  It would seem you have
> read it: do you understand it?  Do you see anything technically wrong
> with it?  If you don't then maybe you could help convince others that
> it's a viable plan

It sounds workable, but I'm not convinced myself that this approach is 
going to be attractive enough for third-party package authors. As well 
as for the author of s.el. And if I don't see it as attractive, what 
hope would I have of promoting it?

First: would the author want to rename it to magnars-string or strings? 
I don't know, both seem more generic than 's.el' which is pretty 
well-known by now. And if you look at some discussions, he doesn't want 
to break compatibility with older Emacs without very good reason.

Second: why is the existence of s.el a problem? Does somebody else want 
to use this name? I could understand it if we wanted to introduce such 
namespace in the core, but as some related discussion has shown, the 
maintainers don't value this kind of naming scheme (consistent prefixed 
naming and very short names), so in the end what? It will sit unused?

The main value of s.el IIUC is in its superficial qualities: the 
easy-to-grasp names, the searchable README.md which lists all the 
methods, and the naming of functions which is friendlier to Clojure 
users. If we take away the naming, what's left is perhaps a dozen of 
added convenience functions.

>> Otherwise, we've just acquired some extra complexity in the reader,
>> xref and elisp completion code, while the anticipated benefits are
>> very slow to materialize.
> 
> I'm not sure the complexity is that much (it was a long time ago, but I
> believe it was reasonably low).  But you're right, the benefits of
> shorthands so far are just programmer convenience for libraries outside
> of Emacs.  I've enjoyed using them, and I would guess a small number of
> programmers are also taking advantage of them them in some side
> projects, judging from a quick GitHub code search.

My own search on GitHub has yielded nothing so far.

>> Half a year has passed now since Emacs 28.1's release, and even longer
>> than that since the "shorthands" have been installed on master, and I
>> don't see a single mention of them on s.el's issue tracker.
>>
>> Ditto for dash.el and f.el.
> 
> For the record, I think you're completely right.  But hey, this is
> Emacs, it moves slowly.  Again, if you understand the plan I put forth
> and you think it's viable, then speak up and let's get things moving.

Third-party packages also usually want to keep compatibility with 
several older Emacs versions. So perhaps we can see some movement when 
the year 2028 rolls over, and I will be proven wrong.