Re: Imports / inclusion of s.el into Emacs

[Adam Porter <adam@alphapapa.net>]

João Távora <joaotavora@gmail.com> writes:

>> One minor drawback I see is that the symbol renaming is placed at the
>> bottom of an Elisp file, while the loading of the library whose symbols
>> are renamed is (usually) at the top of the file.
>>
>> Would a macro something like this be feasible, to (require ...) the
>> library and specify the renamings together?
>>
>>   (shorthand-require 'magnar-string :with "^s-" :as "magnar-string-")
>
> Yes, something like that is reasoanble.  Or we can just have a table of
> "notable renamings", and then the bare (require 'magnar-string) would
> come with that.  Or as Richard, suggested, the default renamings could
> be given in the magnar-string.el file itself.  They could be collected
> within each byte-compile-file or load-file, then restored.  

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.  IOW, it seems almost like solving the problem of
libraries' "polluting" the global symbol namespace by allowing libraries
to "pollute" the global symbol *abbreviation* namespace (in the sense
that one would exist).

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'?  Or what if both magnar-string.el and super.el defined the same
default abbreviation (since there is no enforcing body to prevent
conflicts)?  Shouldn't it be up to the "requiring" library to decide
which shorthands it uses for libraries it requires?

> 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).

I suppose that would be ideal if it's possible.  On the other hand, if a
user wanted to write a package using s.el with a prefix like
"^mstring-", and a hypothetical super.el with the "^s-" prefix, it would
seem confusing for symbols like "s-foo" to not refer to those loaded by
(require 's).  The "don't do that if it hurts" axiom may apply, of
course, but it would seem preferable to avoid such a situation.

> Another thing that has to implemented is a special syntax to escape the
> renamings (imagine that you want to use some legitimate "s-foo" function
> that your renaming has shadowed)

Would a table of buffer-local symbol aliases work?  Maybe it could even
work something like:

  (defalias-local :canonical 's-foo :local 'real-s-foo)

Which would make the canonical s-foo accessible as real-s-foo in the
local buffer's code.  (The keyword arguments may be superfluous, but it
may also help clarify that the s-foo referred to is the canonical one
rather than a "shorthand"-abbreviated one.)  If that were present in the
file before the (shorthand-require ...), I suppose the "'s-foo" would
not be intended to be read with the abbreviation.  (Not commenting on
the feasibility of the implementation, just musing on the user-facing
API.)