record / crecord config options cleanup proposal

Laurent Charignon lcharignon at fb.com
Mon Dec 14 13:48:08 CST 2015



On 12/2/15, 10:23 PM, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org>
wrote:

>
>
>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?

If a user does not want to use curse he/she can set ui.interface=text.
Augie, does that seem too complicated?
I don't really understand the concern here, could you precise your thought?
>
>>>> 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



More information about the Mercurial-devel mailing list