Re: Help sought understanding shorthands wrt modules/packages

[João Távora]

Richard Stallman <rms@gnu.org> writes:

> Now I see why you think this is not necessary.  Your idea for how to
> handle s.el is to use an edited version, edited to specify shorthands.

The magnars-string.el file is meant to supersede s.el and be a
well-behaved version of it.  The s.el file, as it exists today, is a
namespace-polluting liability, we shouldn't maintain it.  The good thing
about shorthands here is that minimal changes need to be done to both
the library and its users, so making packages in (Non)GNU ELPAs and core
start using magnars-string.el is very little effort which is well worth
spending.

>   > Providing two different ways to load an .el file so that each interns
>   > different
>   > symbols into obarray would lead to unfortunate consequences where it would
>   > be hard or impossible for humans or programs to understand the provenance 
> of
>   > a given symbol.
>
> I don't follow you here.  What problems do you see?

If I find a bug or want to add some function to that presumed s.el that
your string.el is loading specially, I have to somehow remember to load
it with shorthands.  The usual commands C-M-x, M-x load-file, M-x
emacs-lisp-byte-compile-and-load will all produce wrong results that I
won't know how to fix.  This is uncharted and dangerous territory: after
your change, information about where to intern symbols of an Emacs Lisp
file would no longer be completely contained in the file itself.

For non-human users, violating this invariant would possibly also break
tools that map files to symbols, such as C-h f (describe-function) and
M-. (xref-find-definition).

João