record / crecord config options cleanup proposal

[Laurent Charignon]

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




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.


4) Send a patch to the crecord maintainer to use the option proposed in 1) and use core's implementation as of the next release of mercurial.
This way, we will avoid further breakage like the one that happened recently.

+2

--
Pierre-Yves David


Thanks,

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151119/94aa2737/attachment.html>