[Top][All Lists]

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

Re: Imports / inclusion of s.el into Emacs

From: João Távora
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Mon, 18 May 2020 23:31:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)

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. ]]]
>   > One thing that I'd like to discuss is whether it's a good idea or not to
>   > rename s.el to magnar-string.el.  Maybe there's a way to keep calling it
>   > s.el and let every client keep using (require 's).
> We could have a file s.el which is not an ordinary file of Lisp,
> but rather a special stub for 'require' to access.

As I told you off-list, this can certainly be done, if we really can't
or don't change existing code that uses the present s.el library.

The stub s.el technique is only, in my opinion, a "nice to have"
requirement.  I don't expect users of magnars.el to be very bothered to
change one or two lines of each file that currently uses s.el.

The hypothesis here is that these users _want_ to be in GNU ELPA, they
have fulfilled all other requirements, but can't easily switch to our
string manipulation techniques.  So, presumably, they won't mind
changing a bit of their code, especially if we show them that they can
do it in a backward compatible way.

> (require 's) would load magnars.el, then set up the renamings for the
> rest of the containing file so that it can say s-foo and that will be
> renamed to magnars-foo.


> The s.el file can include a precise list of the necessary renamings
> for callers to use.  This woud be updated by scanning magnars.el.

I don't understand this particular bit , the "precise list of necessary
renamings").  It simply isn't needed, from my understanding of how the
system works.  Here's an example: say a user.el file has this content

    ;; user.el -- a file which is a user of s.el
    (require 's)
    (defun user-thingy ()
       (message "%s" (s-lines "hello\nworld")))

    (provide 'user)
    ;; user.el ends here

It can remain completely unaltered.  

Thus, when compiling user.el, the byte-compiler will evaluate some
forms, including top-level require forms.  After it has evaluated the
first line

   (require 's)

It has loaded the file s.el[c].  That, in turn will have `require`d
magnars.el and set up the `s-` -> `magnars-` translation for the current
compilation session (probably in a buffer-local version of the
shorthand-shorthands variable).  

>From this point on, back in the user.el file, the reader knows to
replace the 's-' prefix with 'magnars-'.  This means that the .elc file
produced that will eventually be loaded will have references to longname
version of every symbol.  Not only that but during the reading itself,
the `s-lines` symbol was never interned in the global obarray.

So this is really a shorthand system, very much the way shorthands work
in real life: we write AFAIK and IMNSHO for brevity but we the long
names of these things.

Anyway, when loading files something similar happens.

The only think I'm not sure how it should work is if the value of
shorthand-shorthands setup by requiring s.el should then remain in the
buffer for further byte-compilations of evaluations of specific
functions.  I think it should.


reply via email to

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