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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 2 Oct 2021 15:43:03 +0100
> Cc: Phil Sainty <psainty@orcon.net.nz>, 50959@debbugs.gnu.org
> 
> > You are saying that 3 is easier than 2?  Then I think we should do 3,
> > as it's better from the user's POV, right?
> 
> No, I don't know that for sure.  And I don't think it's better from
> the user's POV.
> See my reply to Phil.  It would mistakenly provide the idea that Shorthands
> are some alias to the symbol (in the sense of defvaralias).  They are not.
> 
> The user would then be quite surprised to find the list of completions change
> behind his back as he changes the place of origin of those C-h o calls.

I'm not sure the user will be so much surprised.  We could document
that.  And shorthands aren't supposed to be used massively or
willy-nilly, so these surprises are not necessarily as acute as you
think.  they are certainly not worse than not showing these shorthands
at all.

> It could only make sense if these interactive prompts were clearly tied to
> the buffers they originated from.

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

> In summary, I think that with the exception of a shorthand-aware
> 'xref-backend-references',
> something that I am working on (between the drops of the torrential emails,
> some of them bordering on sheer harassment), this feature is currently
> consistent
> from a tools point of view.

You are saying that Help commands should allow asking about
shorthands, except if point is on the shorthand?  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.

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