bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs

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

On Sat, Oct 2, 2021 at 4:53 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > Because 's-concat' is _not_ a symbol.
>
> I don't see the significance of the difference, from the usability
> POV.

You don't?  Maybe you are still somewhat thinking of shorthands
as similar to the products of defvaralias or defalias.  s-concat
may mean magnar-string-concat in a buffer, and stream-concat
in another.  In that some other buffer magnar-string-concat may
be accessible by the shorthand ms-concat.

This is how namespaces work also in other languages.  In Elisp
in proposals like Andreas Corallo's
(https://akrl.sdf.org/lexspaces/lexspaces.html)
or if Lars' proposed evolution of shorthands to be somehow local
to a specific region to a buffer (like Common Lisp's IN-PACKAGE).

> I'd still like to see Help commands support shorthands even if
> point is not on a shorthand.

Alright, it does need an implementation.  Of unforeseen complexity.
Certainly the most tricky of all the feature so far, I predict,  as it would
affect many more commands. I'm not confident I can muster the effort
to tackle it for Emacs 28, though I can of course experiment (and maybe
it's easier, especially if you help me restrict the feature in scope).

If it's ever done, I think at the very least it should be made
optional, and that the default should be off.

The least of its problems is that, when set to on, it would bring back
some form of namespace pollution: finding too "inexplicably" short
symbol names when perusing global lists of symbols.  What's more,
finding them there only sometimes.

The more serious of its problems is that it would make the evolution
of Shorthands to be local to a region (for example, as I hinted
above) much harder.

Then, it would raise the bar to adopting _other_ namespacing systems
even higher than it already is.

> I don't object, and think it could be useful.  But I don't think it
> could supplant the recognition of shorthands in Help commands.

I think it could, by helping the user keep the correct mental model
in mind.  It could even be made more sophisticated, like temporarily
displaying the full names of the symbols at the point of the symbols when
C-h f is entered. That would be level of integration 1.5 so to speak (in
the scale I gave a while ago).

I think we must focus on the problem being presented here, not on
the particular solution.  _Why_, fundamentally do you want to see
shorthands listed in an Help command? What, in layman's terms,
are the pieces of information that are missing for you when you _don't_
see them?  Is it more like:

   a. "I wonder what that that 's-thingy' over there is/means or what
    documentation there is for it.?"

Or is it:

  b. "I wonder what help on s-thingies I have at my disposal here
   (and yes I know perfectly well what 'here' is)?  I'm going to type a
   prefix, the TAB to find out."

Or is it both? Or is it a third thing?

The question goes for Phil too, though I think I have a better intuition of
what his problem is: I think it's 'a': he fears he won't be able to immediately
tell visually what he's looking at, say in one of his windows that has
an excerpt of a .el file open.  Disregarding the fact that that already
happens with things like  cl-flet or letf, for example (lexical function
definitions), I think it's a legitimate concern (especially coming from
someone with likely no experience of namespace systems at all).

João Távora