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

Previous Next

Full log

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

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

> Date: Sat, 02 Oct 2021 22:20:09 +1300
> From: Phil Sainty <psainty <at> orcon.net.nz>
> 
> Following up on 
> https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg00109.html
> 
> On 2021-10-02 21:53, Eli Zaretskii wrote:
> >> From: Phil Sainty <psainty <at> orcon.net.nz>
> >> On 2021-10-02 19:45, Eli Zaretskii wrote:
> >> > There's a huge difference between breaking literal searches for
> >> > symbols by text-searching tools, and breaking basic Emacs commands
> >> > because the name the user sees and types is not known to Emacs.
> >> 
> >> But shorthands does *both* of those things.
> >> 
> >> The name the user sees is "s-foo".
> >> The name known to Emacs is "string-library-foo" (or whatever).
> >> The user types "C-h o s-foo RET" and Emacs says "no match".
> > 
> > If this is correct (I didn't try), please report it as a bug.
> 
> 
> This was indeed the case in the build I'd compiled for testing:
> 
> GNU Emacs 28.0.50 of 2021-09-29
> Repository revision: b02a7ad2631b6ac3a95e53cb26a0aa1b1ab7e98a
> Repository branch: master
> 
> I tested with a copy of so-long.el in which I renamed all of the
> so-long-* symbols to sl-* and then configured the local variable
> ;; elisp-shorthands: (("sl-" . "so-long-"))
> 
> Loading the new sl.el confirmed that Emacs didn't recognise the
> shorthand symbols generally.

João, if this problem still exists after your changes yesterday, could
you please look into it?  TIA.

Previous Next

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