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

[João Távora]

On Sat, Oct 2, 2021 at 3:20 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Sat, 2 Oct 2021 15:02:41 +0100
> > Cc: Phil Sainty <psainty@orcon.net.nz>, 50959@debbugs.gnu.org
> >
> > > > 0. no integration
> > > >
> > > > 1. This is the current integration.  I.e. when C-h o is pressed on the
> > > >    symbol the global name is discovered and used as the default.  This
> > > >    is how SLIME work with CL's namespacing system.  SLIME is a very well
> > > >    tested and widely appreciated Common Lisp IDE for Emcas.
> > > >
> > > > 2. The shorthands from the buffer where the minibuffer was entered are
> > > >    _not_ in the completions list, but typing one of them interns the
> > > >    symbol with those shorthands present, so you get the desired result.
> > > >    This would fix Phil's visually-copy-and-type scenario.
> > > >
> > > > 3. (Eli's suggestion): the completion list would be augmented with the
> > > >    shorthands from the buffer where the minibuffer was entered from.
> > >
> > > Are 2 and 3 significantly different (from the implementation POV)?
> >
> > I think so.
> >
> > I think 2 can be achieved by setting elisp-shorthands buffer-locally
> > in the minibuffer and removing the "require-match" flag requirement to
> > whatever completing-read call happens there.
> >
> > 3 is achieved by calculating the list of completions using
> > 'elisp--completion-local-symbols` and then filtering it down as usual.
> > "require-match" is kept untouched.
>
> 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.

It could only make sense if these interactive prompts were clearly tied to
the buffers they originated from.  The current "Describe function" prompt
should become "Describe function inside foobarbaz.el" .  Even then, I think
it is insufficient, and uncharted territory, whereas the current approach isn't
(it's how SLIME/SLY work in a Lisp-based IDE with local namespacing)

That _can_ be done, and I think all of Phil's list will eventually
funnel down to
a few existing function calls.  But it nevertheless needs more profound work
and a careful understanding of the consequences.

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.

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.

That is not to say I don't understand Phil's concerns: I do.  I just
don't understand
the feeling of imminent catastrophe.

As I wrote to Phil, I believe much of this anguish is improved if we font-lock
shorthands specially.  That doesn't seem hard at all.  If I understand Phil's
objections from day 1, he is talking about looking at something in an Elisp
buffer and being uncertain about the nature of the thing that his eyes are
focusing.  But if he is _looking_ at it, then we can quench much of that
doubt by changing the way it looks.

If, on the other hand, he is operating on the thing with some other tool [*],
not just his eyes, then I think the current tools are already doing
the right thing.

João

[*]: Yes, except when that tool is Grep or similar, but that's for all namespace
systems ever invented, so if the concern is still Grep, please open another
bug or (yet) another thread.