[PATCH] ui: extract choice from prompt

Martin Geisler mg at lazybytes.net
Mon Jul 6 13:41:44 CDT 2009


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?

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090706/a7dc5473/attachment.pgp 


More information about the Mercurial-devel mailing list