bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

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@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@posteo.net> wrote:
>
>>
>> João Távora <joaotavora@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
>>
>

[-- Attachment #2: Type: text/html, Size: 2248 bytes --]