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

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

On Tue, Nov 8, 2022 at 5:02 AM Richard Stallman <rms@gnu.org> wrote:

> Is that behavior bar?  What behavior would we prefer ElDoc to
> implememt for such cases?  Would we want it to show `x-foo' instead of
> `xenomorph-foo' in the echo area?,

I wouldn't.  It would be misleading.  The shorthand x-foo is only available
locally.

> That seems correct to me.  `xenomorph-foo' is a defined function; why
> shouldn't C-h f know about it?

Yes it is the correct behaviour,  and that's why I implemented it like so.

>   > way you invoke the interactive function defined above is
>   >    M-x xenomorph-foo RET
>   > _not_
>   >    M-x x-foo
> That too seems correct to me.

Same here.

>   >      xenomorph-foo(104)
>   >      funcall-interactively(xenomorph-foo 104)
> I think that is correct, too.  It might be confusing
> if you are looking at the source of x.el and you don't
> notice it uses a shorthand.  Nonetheless, it is correct.

Right again.

My point with these examples was simply to illustrate that a tool
like grep looking for text strings in files "x-foo" isn't guaranteed
to serve us in the presence of a namespacing system.  Here, any
grep for one of "xenomorph-foo", "x-foo" or "xeno-foo" will come up
short in some way, even though these are all ways to reference the
same symbol in some specific context.

My point was also that we shouldn't try to force or limit our uses of
said namespacing system to try and accommodate grep. So while
the "breaks grep" objection does hold some water, it's because grep
is "broken" extremely easily.

But if a tool other than grep were to understand the locally defined
shorthands for every file it visits, then it could very well be useful.
I described such a tool some emails ago.

João

[-- Attachment #2: Type: text/html, Size: 2450 bytes --]