GNU bug report logs -
#59082
28.2; Undocumented `intern-soft` feature with shorthands symbols
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
We can/should of course document the decision that they aren't supported in
rubbed in the manual though (if we make that decision)...
João
On Sat, Nov 12, 2022, 16:46 João Távora <joaotavora <at> gmail.com> wrote:
> Hmm, not sure we should be using shorthands in docstrings, which aren't
> read by the Lisp reader, but by something else... This is what is at stake,
> right?
>
> Maybe if good reasonable semantics can be found, but not sure.
>
> On Sat, Nov 12, 2022, 16:20 Thierry Volpiatto <thievol <at> posteo.net> wrote:
>
>>
>> João Távora <joaotavora <at> gmail.com> writes:
>>
>> > This is a feature of Lisp in general and the correct way to go from
>> > strings to symbols.
>>
>> Great, thanks to confirm.
>>
>> > Curiously, I was pleasantly surprised that much code of key symbol
>> > processing facilities was already using this indirection and
>> > shorthands automatically worked in those facilities because of that.
>>
>> `substitute-command-keys` at least doesn't handle this.
>>
>> Say you have the file foo.el with
>> `read-symbol-shorthands` == (("f-" . "foo-")) and containing definitions
>> like `f-dothis`, `f-dothat` etc... and a var `f-help-string` containing
>> string like
>> "\<f-map>\[f-dothis]: Description", if you define a function `f-help`
>> containing (substitute-command-keys f-help-string) it will fail
>> complaining `f-dothis` is void.
>>
>> --
>> Thierry
>>
>
[Message part 2 (text/html, inline)]
This bug report was last modified 2 years and 217 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.