Re: Imports / inclusion of s.el into Emacs

[João Távora]

On Fri, May 8, 2020 at 3:49 AM Richard Stallman <address@hidden> wrote:

> Thank you for taking back that word.  It hurt my feelings.

My apologies, again

> Or perhaps "Would have a significant drawback"?  That I can agree with
> you about.  Still, it may be the best choice available under the
> circumstances.

I agree.  Under the current circumstances.  But we can work to change
the circumstances.

> was never to use it nontrivially.  Thus I decided, when writing Emacs
> Lisp to, to avoid conflicts by means of name prefixes, and not have
> packages at all.
> However, the state of the art may have advanced since then.

It has indeed evolved since the 1980's.  Most implementations of Common
Lisp now have something called "package local nicknames", which many
find advantageous.  There are proponents and adversaries.  I'm one
of the proponents, and if you wish I can sing you the joys of the CL
package system.  But that can be for later.

Currently, I count around 7 different implementations and even more
vapourware.  The debate over which to choose is likely to be very
lengthy.  In the end we can even choose more than one system.

But we should keep our eyes on the prize, as they say, and resolve
the s.el and dash.el (and also f.el) situation in the shorter term, so
that those free programs can join our ranks without hurting us,
our existing users, or their existing users.

> This week you said there was a kind of namespace system for Lisp that
> works well and avoids those problems.  If that is true, it could be a
> good solution.

Indeed I said so: I was referring to a simple shorthand system.  In this
system, there are no profound changes to how symbols are organized in
Emacs.  Things can have different names in different contexts, much as
"RMS" means something different in Electrical Engineering or in
this mailing list.

> Another obstacle for my reading those messages was that you were
> responding to other people's questions, which were not the same
> questions that I need to understand.
>
> Can you show me programmer's intro to using a package system of the
> sort you're advocating?  I think I could tell what I need to know from
> that.

Yes, that's a good idea.  So our goal is to use the problematic s.el
library without having it pollute our namespace, right?  To do that, we
first load the library shorthand.el (attached to this message) into
our Emacs.

Then, we must change s.el minimally.  Its contents are (very truncanted):

   ;;; s.el --- The long lost Emacs string manipulation library.
   ;; Author: Magnar Sveen <address@hidden>

   (defun s-collapse-whitespace (s)
      "Convert all adjacent whitespace characters to a single space."
    ...)

   (defun s-lines (s)
     "Splits S into a list of strings on newline characters."
    ...)

   (provide 's)
   ;;; s.el ends here,

We need to ask the author to add a few lines to the end of the
file and maybe also change the file name:

   ;;; magnar-string.el --- Now with 99% less namespace pain

   (defun s-collapse-whitespace (s) ...)

   (defun s-lines (s) ...)

   (provide 'magnar-string)
   ;;; magnar-string.el ends here,
   ;; Local Variables:
   ;; shorthand-shorthands: (("^s-" . "magnar-string-"))
   ;; End:

Theoretically, we could avoid this step altogether and "guess" the
shorthand from a list of known problematic cases.

Now, Richard, when you load the new magnar-string.el file into your
Emacs namespace won't be polluted with those two names.  Instead, the
the two symbols will be called `magnar-string-lines' and
`magnar-string-collapse-whitespace'.

In your hypothetical "foobarbaz.el"  you can now:

   (require 'magnar-string)
   (defun f-test () (interactive) (message (cadr (s-lines "this\nworks"))))
   ;; Local Variables:
   ;; shorthand-shorthands: (("^s-" . "magnar-string-") ("^f" . "foobarfaz"))
   ;; End:

Again, by loading foobarbaz.el you will have created the function
`foobarbaz-test', despite having typed `f-test'.

> After that, would you be willing to talk with me by voice so I can
> understand enough to see whether this is a good solution?

Yes.  What voice system do you prefer?  I live in GMT, btw.

João

PS: I attach to this message the shorthand.el file mentioned above,
followed by the modified magnar-string.el.  Please note that
shorthand.el is EXPERIMENTAL.  If you want to try it, you should read it
beforehand (it's less than 50 lines) and load it into a separate Emacs.

magnar-string.el
Description: Text Data

shorthand.el
Description: Text Data