Re: Imports / inclusion of s.el into Emacs

[조성빈 <pcr910303@icloud.com>]

Richard Stallman <rms@gnu.org> 작성:

> [[[ 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)