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

[João Távora]

On Sat, Oct 2, 2021 at 3:56 PM Eli Zaretskii <eliz@gnu.org> wrote:

> But they are: we always know which buffer was the current one when the
> minibuffer is entered.

We "the Emacs code" do. But it's not obvious to a user.  The commands
that invoke these things are global, remember.  I very very often don't know
where I pulled C-h o from.  And I don't want to know. Sometimes I do,
sometimes I don't.

In summary, I wish we can keep the what has been the invariant of Elisp
ever since it was created, and which is underlined many times in the manual:
there is only one obarray of symbols.  I believe my stance preserves this
accurate mental model more than yours.

> You are saying that Help commands should allow asking about
> shorthands, except if point is on the shorthand?

"should NOT allow".  That's what I am saying, yes.  Any command that operates
on _symbols_ should not offer shorthands as candidates unless the goal of that
command is to directly modify the buffer where those shorthands have meaning.

So C-h o is in the former group.  C-M-i s in the latter.

> That'd be a grave
> restriction, I think, worse than "depending on the buffer" which you
> don't like: here it depends not only on the buffer, but also on
> position of point in that buffer.

I don't agree, but ultimately it's your call.  Notice (maybe watch the
.gif again),
that what happens when you type C-h o on 's-concat' is that the prompt becomes:

   "Describe symbol (default magnar-string-concat): ... "

It does _not_ become:

   "Describe symbol (default s-concat): ... "

Because 's-concat' is _not_ a symbol.

> > Again, Shorthands are buffer-local textual indirections to symbols.  They
> > are not the symbol.  This will never change (not with Shorthands): so 
> > including
> > shorthands in a list of symbols is misguided.  Displaying them in
> > lists of fragments of
> > text to be completed in the buffer is not.
> I think this is unnecessarily radical POV, and one that will cause
> complaints.

It hasn't in SLIME/SLY and package-local-nicknames have existed for
quite some time there.

What is your opinion on the visually annotating font-lock idea?  I think
it's useful even if we decide to go with levels 2 or 3 of the above
integration (which, as I said, I think we shouldn't, not for now)

João