Re: Help sought understanding shorthands wrt modules/packages

["João Távora" <joaotavora@gmail.com>]

Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > 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.
>
> No one would be happer than I to eliminate te usual version of s.el,
> but my understanding is that that would cause a big practical problem.
>
> Lots of packages do (require 's), and they call those functions by the
> names s-... defined in s.el.  If we don't have s.el, they will break.
> They can't use your proposed magnars-string.el (which I would call
> stris.el), since the names it would define are wrong _for them_.

I don't think you're following my plan, which was the plan all along.

Here's the story from the beginning:

* Once upon a time, s.el was a namespace polluting liability, and this
  was part of the reason why it wasn't in GNU Emacs or GNU ELPA.

* s.el was a very popular kid.  Many other packages foo.el and bar.el
  depended on it.  They were also popular.  But the namespacing
  pollution of s.el prevented us from including those in GNU ELPA, too.

* Right, so we wanted to integrate s.el into Emacs core or GNU Elpa
  "somehow", but how could we do that?

  We developed shorthands for Emacs 28.

* OK, but what did we do with them?

  We made a new file magnars-string.el which was absolutely identical to
  s.el but for the local read-symbol-shorthands cookie (and the provide
  form.)

  Then we submitted mangnars-string.el to Emacs core or GNU ELPA.

* When foo.el and bar.el wanted to enter GNU ELPA, they just upgraded
  their string library from s.el to magnars-string.el, of course.

* Oh no, but wasn't upgrading them so very complicated?

  No at all, it amounted to changing a single line, in foo.el:
    (require 's)
  to
    (require 'magnars-string)

  And adding the SAME read-symbol-shorthands cookie in the trailer of
  the file.

  ;; foo.el ends here
  ;; Local Variables:
  ;; read-symbol-shorthands: (("s-" . "magnars-string-"))
  ;; End:

* But but, what about all the the references to s-trim and s-append in
  lines 1234 and 876 of foo.el?  

  They became, magically, references to the symbols magnars-string-trim
  and magnars-string-append.

* And that's all?  They lived happily ever after?

  Yes, that's about it.  The usual copyright stuff was changed in foo.el
  and bar.el, the name of the package was endelessly bikeshed, Stefan
  Monnier submitted many patches (mostly for pcase usage), and yes, they
  lived happily.

Epilogue:

* One night, Saint Ignucius came down to tell the world not to use s.el
  anymore, because a better version had appeared in GNU land.  This
  being a world of sinners, most of it didn't listen or care.  Splitters!

  Saint Ignucius then also asked the maintainers to stop maintaining
  their s.el.  Let's presume they did listen.

  One day, some package fossil.el, which didn't listen, found a bug in
  its s.el dependency.  Should that bug have been fixed in s.el?  No, it
  was fixed in magnars-string.el.  fossil.el was told to upgrade to
  magnars-string.el, because it is very easy.  Now fossil.el was
  enlightened, too.

  Not so fast! fossil.el was meant to work on Emacs 27 and Emacs 6 and
  Emacs 500BC!  No problem, that's didn't change the plan.  fossil.el
  was upgraded to use magnars-string.el anyway.

  And that new fossil.el was loaded into Emacs 27 along with
  magnars-string.el.  They loaded fine, and the presence of the
  read-symbol-shorthands file-local variables there didn't affect it.

  And fossil.el worked just fine there.  The namespace was polluted with
  s- symbols, that's true, but the situation was no worse than before.

  One day, the user simply upgraded to Emacs 28, kept all his packages
  in the same place, and the namespace pollution simply went away.

>   >   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.
>
> I don't follow you.  I don't see why anything would produce wrong
> results.  If you show me a specific scenario, I might understand.

If you do these actions in the s.el file, the one where the actual code
is and the one you want to keep unchanged, it will just intern new
s-prefixed symbols in the obarray!  I.e. you won't change the renamed
symbol's definition -- the one begotten by that load-with-shorthands
call -- at all.