GNU bug report logs - #50959
28.0.50; Shorthand symbols are unknown to Emacs

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, 50959 <at> debbugs.gnu.org
Subject: bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs
Date: Sat, 2 Oct 2021 16:22:51 +0100

On Sat, Oct 2, 2021 at 3:56 PM Eli Zaretskii <eliz <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.