Re: Imports / inclusion of s.el into Emacs

[Phillip Lord]

I would set this against the cognitive overload of the current API which
is difficult and complex to remember, because of its lack of
consistency, and low level nature. This is in addition to the it's
tendency to side-effect, particularly with moving point, hence the
necessity for regular use of save-excursion.

s.el (like dash, f.el) provides a clean API, documented at a single
point. Of course there is a maintaince cost, but people have already
written these packages and are maintaining them. They also help to
provide a breath of modernity, and familiarity for newer developers.

There is a reason that s.el is currently registering 2 million downloads
on MELPA -- part of that will come from downloads in continuous
integration of course, but this is a large number. Perhaps you think it
is gratuitous, but many other people do not.

Phil


Richard Stallman <address@hidden> writes:

> [[[ 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. ]]]
>
> You're proposing that we adopt a policy of adding functions to Emacs's
> standard name space as if that cost nothing.  Any function that anyone
> thinks provides the tiniest simplification, we would add.
>
> Adding so many functions would be detrimental in many ways.
>
> Perhaps nowadays the increased computer memory size would not matter.
> It would not matter for five or ten new functions; for hundreds,
> perhaps it would.  But computer memory size is the smallest part of
> the problems they would cause.
>
> There is also human memory size.  That policy would mean more names
> that every Emacs Lisp programmer would need to remember.
>
> It would mean more names to document in the Emacs Lisp Reference Manual.
>
> It would mean more pages to print the Emacs Lisp Reference Manual,
> making it cost more.
>
> It would mean more text to maintain when something changes.
>
> With such a weak thresold for adding a functionb name, we would have
> these costs over and over.
>
> The cl library caused these problems.  It was not gratuitous -- it
> provided useful features.  But eventually we decided that no package
> included in Emacs can use the cl library an run time.  We fix packages
> to use those facilities in other ways that don't pollute the namespace.
>
> I suggest we adopt the same policy towards s.el, which is entirely
> gratuitous.
>
> We can also improve the standard names for string functions.  They
> were invented a few at a time, and there is room to make them more
> systematic.
>
> This way we would get the improvement that is actually useful, while
> paying much lower costs in incompatibility and bloat.  The s.el
> approach is designed to maximize the costs.