[PATCH] ui: add new config flag for interface selection
Laurent Charignon
lcharignon at fb.com
Thu Feb 11 11:37:25 EST 2016
> On Feb 10, 2016, at 5:34 AM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>
>
>
> On 02/04/2016 06:28 PM, Laurent Charignon wrote:
>>
>> From the problem that Pierre-Yves mentioned, we have resolved 2 issues out of 3:
>>
>> 1) In what section to put this code.
>>
>> => RESOLVED: We are going to stick to what I sent in the patch, i.e. ui.interface.XYZ
>
> Keep in mind that the main entry point should be 'ui.interface' and that hopefully most user will never touch anything else (well actually not touch it all)
>
>
>> 2) What should the config value be
>>
>> =>NOT RESOLVED: Augie thinks that we won't have a second curses interface and wants to simplify the option choice accordingly.
>> Pierre-Yves disagrees and prefers to keep a more complex but more flexible option.
>> I am personally fine with any choice, but I prefer Pierre-Yves' idea as it is more extensible, let's be optimistic, we could have another curses interface one day!
>
> My opinion here is that we should have a hierarchical option value.
>
> - "curse" is a valide option value and mean "the best curse available",
> - "crecord" is a valid option value and mean "the interface we imported from crecord",
> - "blackpearl" will be a valid option value and mean "another immortal curse UI".
>
> This give us the following tree:
>
> - "curse"
> - "crecord"
> - "blackpearl"
>
>
> That said, we do not need this tree structure until we actually get more UI. So here my proposal:
>
> - We call the option "curse",
> - If we get another option we implement the tree structure,
> - We make it somewhat clean that script should not rely on this "curse" value for backward compatibility (but, we are talking about a curse UI here)
> - If the Point above seem to sloppy to other people we introduce both "curse" and "crecord" and make it clear that "crecord" only ensure backward compatibility.
Ok I am good with that! I will send a V4.
Thanks,
Laurent
>
>
> --
> Pierre-Yves David
More information about the Mercurial-devel
mailing list