Re: [drew.adams@oracle.com: RE: Customize doc strings and tagstrings do not respect \\<...> and \\[...]]

[Andreas Schwab <schwab@suse.de>]

"Drew Adams" <drew.adams@oracle.com> writes:

>     > (defcustom titi 'tata "OK" :type
>     >  '(choice
>     >    (const :tag "`\\<minibuffer-local-map>\\[next-history-element]'."
>     >           tata)))
>     > I see in Customize what I reported initially:
>     > \<minibuffer-local-map>\[next-history-element] (one level of
>     > \ removed).
>
>     Why do you think this is a bug?  The tag contains exactly this text.
>
> What are you saying?
>
> The point (the bug) is that the tag text should implicitly have
> `substitute-command-keys' applied to it.

The connection between doc strings and widget tags is not immediately
apparent, but of course this could be added as a new feature.  But note
that this would change the rendition of existing :tag strings since
certain construct in the text would have to be quoted now.  Current only
doc strings are filtered through substitute-command-keys (via
documentation-property).

>     No.  This is the correct rendition of \<my-map> when my-map is not
>     defined.
>
> If one defines "correct rendition" by whatever the program does currently,
> then of course there can be no bug. "Circulez, il n'y a rien a voir!"

That's how substitute-command-keys has always been working, and it is not
a useless feature.  It helps to interpret subsequent renditions of \[...]
(the commands might be bound in a different key map that is current at
this point).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."