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: Richard Stallman
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Wed, 06 May 2020 22:45:10 -0400

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

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.  They would demand that we give priority to the usual
Clojure-based names 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?"

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]