emacs-devel
[Top][All Lists]
Advanced

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

Re: Help sought understanding shorthands wrt modules/packages


From: Richard Stallman
Subject: Re: Help sought understanding shorthands wrt modules/packages
Date: Thu, 10 Nov 2022 23:35:14 -0500

[[[ 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. ]]]

  > > >     ** Shorthands for loading a file can be specified from "outside".
  > > >
  > > >     The new function `load-with-shorthands' loads a file
  > > >     and specifies additional shorthands for reading it.

  > I think it's fair to say, as the person who originally implemented
  > shorthands,
  > that I don't agree with this change.

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.

Thus, we would have a file magnars-string.el in GNU ELPA, or perhaps
in the core, and a nearly identical file s.el in NonGNU ELPA for
compatibility's sake.

(Thanks for reminding me that the developer's name is Magnar.
I was trying to remember it, but lacking a copy of s.el I knew
where to find, I couldn't check.)

We would need to update the two files in sync every time.

I did not think of doing it that way, because I think it is asking for
trouble.  We should have only one copy of s.el, and it should be the
usual released version.

Thus, instead of making a modified version magnars-string.el,
we would have string.el load s.el with added shorthands.
We would never have two versions of that file, only one.

Another point of disagreement is that you envision advising users
to load magnars-string.el rather than string.el, and make it
something that only some users would do.

People have said that s.el is very useful.  So I envision making it
standard and documenting those functions in the Emacs Lisp Reference
Manual.

Maybe we should even preload them.

  > 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?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





reply via email to

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