[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: RE: Customize doc strings and tagstrings do not resp

From: Andreas Schwab
Subject: Re: address@hidden: RE: Customize doc strings and tagstrings do not respect \\<...> and \\[...]]
Date: Sun, 05 Mar 2006 11:17:24 +0100
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux)

"Drew Adams" <address@hidden> 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

>     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 Schwab, SuSE Labs, address@hidden
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."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]