RE: address@hidden: RE: Customize doc strings and tagstrings do not respect \\<...> and \\[...]]

[Drew Adams]

    > (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. I made that clear in my initial
report. A :tag string should be treated, in this respect, the same way a doc
string is treated.

Use case: You have a choice between two values for an option. Each controls
the behavior of `next-history-element' in a different way. You want to be
able to use `\\<minibuffer-local-map>\\[next-history-element]' in the :tag's
to refer to the command binding. You don't want to hard-code the binding in
the :tag string.

    > 2. BTW, if I eval the defcustom I sent originally (quoted
    > above), without
    > defining `my-map', then I get this in Customize, with a
    > warning message
    > spliced into the middle of the key description:
    >
    >  Behavior of ` Hide Rest
    >  Uses keymap "my-map", which is not currently defined.
    >  M-x my-cmd' when foobaz is in the wind.
    >  Parent groups: Nil
    >
    > This appears to be another bug.

    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!"

Does that "rendition" look correct to you? Splicing in the error message in
place of the \\<...>?  With a button ("Hide Rest") inside the string `...'
along with the message?  Do you think this is the best way to present such a
message? Not to mention that (presumably) part of the message is missing
(just what is it that "uses keymap..."?).

I cannot believe that someone would look at that Custom buffer and say that
there is no bug, that this is what we should present to users. The UI should
not compound the problem of an undefined map by making a mess of things. It
is not the user's fault that the map is undefined; the UI should aid the
user as best it can, not throw up at him.

These might not be earth-shaking bugs, but that is no reason to close them
cavalierly, with an attitude that the program does what it does. Put them on
the back burner if you don't think they are important or don't want to work
on them, but please don't take the attitude that whatever is is right.