[Top][All Lists]

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

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

From: João Távora
Subject: Re: A short defense of shorthands.el (but CL packages are still better)
Date: Sat, 05 Nov 2022 01:09:06 +0000
User-agent: Gnus/5.13 (Gnus v5.13)

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

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

reply via email to

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