[PATCH] ui: add new config flag for interface selection

[Pierre-Yves David]

On 01/11/2016 07:25 PM, Augie Fackler wrote:
> On Thu, Jan 07, 2016 at 08:18:06PM +0000, Pierre-Yves David wrote:
>>
>>
>> On 12/23/2015 05:30 AM, Laurent Charignon wrote:
>>> # HG changeset patch
>>> # User Laurent Charignon <lcharignon at fb.com>
>>> # Date 1450848537 28800
>>> #      Tue Dec 22 21:28:57 2015 -0800
>>> # Node ID 3e4f77c0bd16c78f2de991b483325eef1dc6f3fb
>>> # Parent  fe376159a58d9b3d748b669ac011b0eed0346fea
>>> ui: add new config flag for interface selection
>>>
>>> This patch introduces a new config flag ui.interface to select the interface
>>> for interactive commands. It currently only applies to chunks selection.
>>> The config can be overridden on a per feature basis with the flag
>>> ui.interface.<feature>.
>>
>> I noted 3 points raised in various people replies
>>
>> 1) In what section to put this code.
>>
>> 2) What should the config value be
>>
>> 3) What happen when the specified value is unknown.
>>
>> Given that Laurent have been talking about this for months and send details
>> on his plan a descent amount of time ahead of this series. I would be fairly
>> disappointed if we can't allow him to land that before the freeze.
>>
>> While we discuss this points, I'm tempted to move forward with Laurent code
>> and proposal. Making changes to it as we get consensus on the above
>> questions. What do you thinks?
>
> Please do not take this patch without consensus. It's outside the
> [experimental] region, so if we start with 'crecord' as an enum option
> for interface, we're stuck with it forever, and that'd be a shame IMO.
>
> (If I'm wrong and this is somehow inside the surface area of
> experimental, I'd still rather we got consensus rather than taking
> something half-discussed.)

We seems to have consensus on (1) "config name" [waiting for 
confirmation from yuya] and (2) "config value". (3) "behavior on bad 
value" seems minor and simple.

Are you okay with us moving forward with an adapted version of this series?

[…]

>> I can imagine we'll eventually end up with a tree in the spirit of this
>>
>> - auto: take "best" available one,
>>    - curse:
>>      - crecord:
>>      - compact:
>>      - thg (the text version!)
>>    - editor:
>>      - histeditdropmissing
>>    - gui:
>>      - thg:
>>      - qtcommit
>>
>>
>> So I think, we should use "curse" as the top level one, used as a synonyms
>> for "the best available curse UI we ship".
>
> I'm okay with this, with the caveat that I think *today* the option to
> enable crecord should be "curses" on the "you're never actually going
> to make a second curses-based UI" theory. I'd also rather
> ui.interface=curses was a globally-sane thing for all curses-type UIs
> (I'm assuming that the median user will want a similar UI type for all
> commands), rather than baking crecord into the config naming
> today. Does that seem reasonable?

Yep, I think we have a consensus on that.


-- 
Pierre-Yves David