[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help sought understanding shorthands wrt modules/packages

From: Dmitry Gutov
Subject: Re: Help sought understanding shorthands wrt modules/packages
Date: Mon, 14 Nov 2022 03:03:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]