record / crecord config options cleanup proposal

raf at durin42.com raf at durin42.com
Sat Nov 21 15:54:47 CST 2015


On Tue, Nov 17, 2015 at 07:18:01PM +0000, 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.

I'm -0.5 on curses being the /default/ interface for commit
--interactive if the (eventual) goal is to mark record as a deprecated
extension/command name (which I'd like to do). Right now it's *WAY*
too hard to disable curses when it's going to be inconvenient (I have
an ugly alias [0] for when I want crecord, precisely because this is
so cumbersome.)

0: https://bitbucket.org/durin42/dotfiles/commits/7fa854682fdd225197c5fa392ded7110d44cf482


> If the user picks "yes" and curses is not available, we would print an error.
>
> 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.
>
> 3) Keep experimental.crecordtest as is

+1>

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

Alternatively, if crecord is in mainline now, why not have crecord
poison-pill itself if it sees a recent hg?

>
> Laurent
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list