emacs-devel
[Top][All Lists]
Advanced

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

Re: Imports / inclusion of s.el into Emacs


From: 조성빈
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Fri, 8 May 2020 00:29:30 +0900

Richard Stallman <address@hidden> 작성:

[[[ 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 have the impression that you don't live in the same universe as mine:

If your universe is limited to Emacs Lisp packages outside Emacs, then
indeed I am living outside your universe.  I never come in contact
with them.  If you would like me to know about those, how about telling
me from time to time?

in my world, `s.el` is already used by the majority of new packages even

If that is so, it is quite unfortunate.  But things could get worse:
we could include s.el in GNU ELPA, or even in Emacs itself, and thus
spread its influence even wider.

You know what? By these explicit decisions, ELPA is close to useless in the
Emacs community, MELPA is the biggest repo, and since MELPA isn’t ELPA, it
already has proprietary packages that a lot of people rely and use.

I personally dislike all of that free software movement, but by alienating 99%
of Emacs users for the sake of elisp purity (which frankly doesn’t make sense
at all, I didn’t try to use strong words in the previous discussions but
Elisp’s API naming is just such a terrible mess and has zero consistency, some new package that at least has some internal consistency doesn’t make it worse)
will push people to use MELPA much more, and people will find it much easier
to install proprietary Emacs plugins. I’m pretty sure you would hate that?

(For an example, check out the https://github.com/TommyX12/company-tabnine
 plugin that works with the tabnine GPT code completer that’s proprietary,
 which I already know quite a few people use it.)

We could tell ourselves that this was merely an extension users could
use or not.  But that would be closing our eyes to the situation.

For instance, people would complain that these "essential facilities
that so many packages use" were not in the Emacs Lisp Reference
Manual.

That looks like a valid complaint, it’s just that essential facilities aren’t
in Emacs, not Eintr.

They would demand that we give priority to the usual
Clojure-based names

No, people will demand names with consistency, not Clojure-based names. And
the only reason s.el used the Clojure API as a base is that they actually
consider the users and design a proper API, they do not say that you can look
names up on the manuals.

and relegate the "irregular" 'concat' and 'format'
to an appendix.

If we did not comply, they would bombard us with verbal aggressions
such as, "We are the majority, what universe are you in?"

That’s quite true, I can guarantee that 99% of Emacs users don’t know what
mailing lists are, why there are crazy names like assq, and just think that
Emacs has this crazy API just because some old timers designed it. Emacs
package developers find the API strange and make packages like s.el, a usual
Emacs user gets alienated with the API. People are already in a different
universe with emacs-devel. And this whole discussion was about trying to merge
them, and everybody is like one can use C-h a, C-h d, and that’s how lisp
works.

Likewise if we defined other Emacs Lisp functions with names starting
with 'string-', departing from Clojure's spec, they would accuse us of
risking a name conflict with future Clojure extensions.

Rather than let that happen, we should say no at the outset.

However, a small change would avoid these problems.  We could rename
the file to clostring.el and rename the functions to start with clo
also: clostring-prepend, clostring-format, etc.

This file would do the same job as s.el, but including it in GNU ELPA
or in Emacs itself would not have the negative effects I described
above.  It would truly be simply an extension that programmers could
use or not.  There would be no reason not to include it.

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





reply via email to

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