[PATCH 3 of 5 V2] ui: change flag for curses interface to ui.curses
lcharignon at fb.com
Mon Jun 1 12:09:55 CDT 2015
On 6/1/15, 2:16 AM, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org>
>On 05/29/2015 10:29 AM, Laurent Charignon wrote:
>> # HG changeset patch
>> # User Laurent Charignon <lcharignon at fb.com>
>> # Date 1432850639 25200
>> # Thu May 28 15:03:59 2015 -0700
>> # Node ID 2a54d1ceebeac71129f211be67fc2876d01674c2
>> # Parent 9e29b782004467e1837c6ddae7091afeda50e485
>> ui: change flag for curses interface to ui.curses
>> Before this patch the flag for the curses interface was
>> Since this is a ui feature that is no longer experimental we change the
>> flag to ui.curses. We don't have to worry about retrocompatibility as
>> feature was experimental.
>I just remind why I was anxious about seeing this "final option name"
>discussion starting. It is because the topic is very complicated.
>First, the usual pattern for option like 'curse' 'color' 'mouse' etc is
>to have three value. "yes", "auto", "no" (yes/no can be true/false).
>- yes: make this happen or die
>- auto: try to make it happen and skip if you think it will fails
>- no: skip this feature.
>"yes" is important to have so that (1) people can bypass wrong
>detection, (2) people can have a plain crash to debug.
>"auto" is usually the default value (of something enabled by default, so
>Do we want this option to be called "curse", curse is a fairly clear
>term for people who have done terminal programming and ... that is about
>it. Should we find a better name and if so, which one? 'advanced'
- I think it is better to be clear on what it entails, "curses" seemed
clear to me, does it shock anyone?
- Advanced makes the assumption that we can do more things than with the
alternate interface, that is not the case.
- Fullscreen also seems off:
- record's curses interface uses the full screen but it won't
necessarily be the case of other curses feature we could have in the
future, isn't it?
>But actually, the question is a bit wider,
>1) There will be other commands that could make use of curse (eg:
>histedit, annotate, evolution based history viewing, etc). Do we really
>want a global switch for all of them? How would that config work?
These sounds like interesting ideas of future development, yet, I think
that we are thinking too much ahead of us.
I don't want to plan for all the future alternatives of curses before
knowing that someone will be working on it.
>2) There will be likely other -interface- to do this chunk selection. A
>regular idea is to fire a merge tool up and let the used select the
>change through it (eg: base, result, allchange). So do we want a more
>versatile option. eg:
> chunkselector=text (default)
>Some alternative option could event be also based on curse if someone
>comes with a better alternative.
Same comment than above, let's not get ahead of ourselves.
More information about the Mercurial-devel