[Top][All Lists]

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

Re: Imports / inclusion of s.el into Emacs

From: Richard Stallman
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Wed, 13 May 2020 00:05:42 -0400

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

  > I may be missing something, but it strikes me as almost duplicating the
  > original problem, if libraries are allowed to define their own symbol
  > abbreviations.

That depends on how a library would specify them.  If it could be
arbitrary string substitutions, it might have this consequence.
Joao and I are talking about how to make it more controllable.

  > Similarly to what you said, what if one user wants to write a package
  > using magnar-string.el with the "^s-" abbreviation, but another user
  > wants to write a package using a hypothetical super.el with the same
  > abbreviation, and both magnar-string.el and super.el define a symbol
  > `foo'?

There is no conflict.  In the first package, s-foo expands into magnars-foo.
In the second package, s-foo expands into super-foo.
Neither one actually uses the symbol s-foo.

For that reason, we must not try to specify what the "canonical meaning"
of s-foo is.  It can have multiple ones.

If you wanted to use both magnars.el and super.el in one program,
you'd have to turn off the renamings for one or bot of those two.

Dr Richard Stallman
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]