GNU bug report logs -
#50959
28.0.50; Shorthand symbols are unknown to Emacs
Previous Next
Reported by: Phil Sainty <psainty <at> orcon.net.nz>
Date: Sat, 2 Oct 2021 09:21:01 UTC
Severity: normal
Found in version 28.0.50
Done: João Távora <joaotavora <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
(Until now I was under the impression that this was all part and
parcel of the shorthands feature, but it turns out that it's a bug.)
-Phil
This bug report was last modified 3 years and 223 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.