[PATCH] ui: extract choice from prompt
Steve Borho
steve at borho.org
Mon Jul 6 13:44:40 CDT 2009
On Mon, Jul 6, 2009 at 1:41 PM, Martin Geisler<mg at lazybytes.net> wrote:
> Simon Heimberg <simohe at besonet.ch> writes:
>
>> Am Samstag, den 04.07.2009, 16:14 +0200 schrieb Martin Geisler:
>>> Simon Heimberg <simohe at besonet.ch> writes:
>>>
>>> > # HG changeset patch
>>> > # User Simon Heimberg <simohe at besonet.ch>
>>> > # Date 1245539599 -7200
>>> > # Node ID b615ecb9cc81f6c48b4cbcaf2dc1b05a9006bd75
>>> > # Parent fc1cfff940fdb1b3ef3badad42d29135e6ee1120
>>> > ui: extract choice from prompt
>>> >
>>> > avoid translating single characters (as l for _local or sym_link)
>>>
>>> Does anybody object to this patch? I just tried applying it and it
>>> passes all tests.
>>>
>>> I was wondering if it would be possible to make the return value a
>>> string instead of a number. Something like this where the names of
>>> the keyword arguments become the return values:
>>>
>>> r = ui.promptchoice("are you sure?",
>>> yes=_("&Yes"), no=_("&No"), help=_("?"))
>>>
>>> if r == "yes":
>>> # do it!
>>> elif r == "no":
>>> # don't do it
>>> elif r == "help":
>>> # give help
>>>
>>> But then I remembered that there's no ordering of the keyword
>>> arguments... Using a list instead does not look good:
>>>
>>> r = ui.promptchoice("are you sure?",
>>> ('yes', _("&Yes")),
>>> ('no', _("&No")),
>>> ('help', _("?")))
>>>
>>> So maybe integers are okay after all.
>>
>> Returning strings looks more understandable. Why is the ordering
>> important?
>
> Well, I thought the valid reponses were printed to the user, but now
> that I look again I see that this is not the case.
>
> However, I believe the interface with the list of choices with "&Word"
> entries was made to support other interfaces -- like a graphical dialog
> box. There it would make sense to present the buttons in a nice order.
>
> But I don't know if it was ever used like that?
THG 0.8 does use the new ui.prompt() interface. I think the ordering
should be enforced, if possible.
--
Steve Borho
More information about the Mercurial-devel
mailing list