record / crecord config options cleanup proposal

[Pierre-Yves David]

On 11/19/2015 10:36 AM, Laurent Charignon wrote:
>
>> On Nov 19, 2015, at 1:39 AM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org
>> <mailto:pierre-yves.david at ens-lyon.org>> wrote:
>>
>>
>>
>> On 11/17/2015 11:18 AM, Laurent Charignon wrote:
>>> Hi all,
>>>
>>> This email is my plan to cleanup config options for record / crecord.
>>> Feel free to chime in with any suggestions / counter-proposal.
>>>
>>> Current behavior:
>>> -----------------
>>>
>>> For commit -i and revert -i is:
>>> - Use the non-curses interface by default.
>>> - If experimental.crecord is set to True, use the curses interface
>>> instead of the the regular interface
>>>
>>> For revert -i only: revert.revertalternateinteractivemode can be used
>>> to invert how the chunks are selected.
>>> This was introduced after a debate on the list about how to display
>>> the changes.
>>>
>>> Finally, we use experimental.crecordtest to specify a file containing
>>> commands.
>>> This was introduce to make it easier to test the curses interface.
>>>
>>>
>>> Proposed changes:
>>> -----------------
>>>
>>> 1) Make crecord no longer an experimental feature but the default
>>> interface relying on a config called ui.cursesinteractiveselection
>>> that can be set to auto/yes/no.
>>> auto would be the default value.
>>> If the user picks "auto" and curses is not available, record's
>>> interface would be use instead.
>>> If the user picks "yes" and curses is not available, we would print
>>> an error.
>>
>> The cursesinteractiveselection selection name is a bit too long in my
>> opinion. It gets hard to read, easy to typo painful to include in help
>> and tutorial.
>>
>> +1 for having some automatic semantic (picking the "best" available)
>>
>> I'm sure a boolean value is the right choice here. We'll likely have
>> multiple possible UI:
>>
>> - current record UI
>> - current crecord UI
>> - other future curse based UI
>> - other GUI based UI
>>
>> In the same way, we'll have more commands/types with interactive UI.
>> for example the chistedit UI offer a curse way to interact histedit,
>> warning you about potential conflict as you swap changeset around. So
>> we have to keep a door open to configure different UI for different class.
>>
>> My personal brain dump:
>>
>> - We want a global option while keeping door open for "type" level UI
>> pick.
>>
>> - We (upstream) are going to make choice on the main recommended UI
>> and that might/will evolve over time. This is interactive and user
>> oriented. I think it is fine to be flexible here.
>>
>> - We'll have more UI in the future. We'll want a way to specify global
>> category wish "prompt", "curse" → best option in that category.
>> "curse.crecord" the current crecord UI explicitly.
>
> Here is an example to make sure that I get what you are suggesting.
>
> So to use histedit standard's interface and crecord for hunk selection
> we would do something along the lines of:
>
> ui.guiinterface = curses
> histedit.gui = text
> # implicitly we have patch.chunkselector = crecord because guiinterface
> (global switch) is set to curses and crecord is the 'default' curses
> interface
> Or the equivalent:
>
> ui.guiinterface = text
> patch.chunkselector = crecord
> # implicitly we have histedit.gui=text because ui.guiinterface (global
> switch) is set to text

Yep, something in that spirit. Probably all in the ui section:

ui.interface = curse
ui.interface.histedit = text
ui.interface.chunkselector = crecord

Augie concern is about "Having an easy way to disable curse when 
wanted". How would we address that concern with this idea?

>>> 2) Get rid of revert.revertalternateinteractivemode and keep its
>>> default value to match what hg diff returns.
>>> This was the idea supported by Pierre-Yves and most people seemed to
>>> agree with it.
>>
>> +1
>>
>>> 3) Keep experimental.crecordtest as is
>>
>> IF we know we want to for good, should move into the devel section?
>
> Sure let's do that.

Or if this is used in a single test, this could probably be in its own 
test extensions.

-- 
Pierre-Yves David