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

Previous Next

Full log

Message #53 received at 50959 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: psainty <at> orcon.net.nz, 50959 <at> debbugs.gnu.org
Subject: Re: bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs
Date: Sat, 02 Oct 2021 18:53:07 +0300

> From: João Távora <joaotavora <at> gmail.com>
> Date: Sat, 2 Oct 2021 16:22:51 +0100
> Cc: Phil Sainty <psainty <at> orcon.net.nz>, 50959 <at> debbugs.gnu.org
> 
> > 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.

I don't see the significance of the difference, from the usability
POV.  I'd still like to see Help commands support shorthands even if
point is not on a shorthand.

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

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.

Previous Next

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