Re: A short defense of shorthands.el (but CL packages are still better)

[João Távora]

Richard Stallman <rms@gnu.org> writes:

> If that's what files x.el and yummy.el contain, 
> I don't think anyone will grep for `xenomorph-foo'.
> The code in yummy.el actually says `x-foo', so that
> is what someone will grep for, and grep will find that in x.el.
> So I don't think this case causes any problem with grep.

As you know, he underlying interned symbol is xenomorph-foo, and that's
the symbol that the at-point documentation system ElDoc shows you in the
echo area, and that's what shows up C-h f.

But I see what you mean: in this particular example, we're lucky enough
that both yummy.el and x.el define the same shorthand.  So it wasn't a
good example.  But we could have a perfectly reasonable z.el that
defines:

   ;; read-symbol-shorthands: (("xeno-" . "xenomorph-"))

And here, xeno-foo now means the very same symbol xenomorph-foo.  And
this "breaks grep".  Not literally, of course just in that it undermines
the user's ability to use grep to know where in source code the Lisp
symbol xenomorph-foo is mentioned.

My point is that this is common to all namespacing systems, across every
language.  Although in different languages and systems we may have
different ways to work around the problem.