[PATCH 3 of 5 V2] ui: change flag for curses interface to ui.curses

[Kyle Lippincott]

On Mon, Jun 1, 2015 at 10:09 AM, Laurent Charignon <lcharignon at fb.com>
wrote:

>
>
> On 6/1/15, 2:16 AM, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org>
> wrote:
>
> >
> >
> >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
> >>experimental.crecord.
> >> Since this is a ui feature that is no longer experimental we change the
> >>config
> >> flag to ui.curses. We don't have to worry about retrocompatibility as
> >>the
> >> 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.
> >
> >Topic 1
> >-------
> >
> >
> >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
> >not yet).
>
> Sure
>
> >
> >Topic 2
> >-------
> >
> >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'
> >'fullscreen' ?
>
> - 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?
>
> >
> >
> >Topic 3
> >-------
> >
> >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.
>

Well, let's say that in the future there's a non-$EDITOR, curses-based
histedit UI available.  How do we release it, if there's a generic
"ui.curses"?  Does it just automatically apply once curses-based histedit
lands in not-experimental?  That seems like it might break some stuff.

I'd probably go for something like 'record.ui=curses' or something like
that.  I can easily conceive of a future once we have a few different ui
alternatives to have some selector that applies automatically, instead of
needing to specify it for each command, but until we have at least two, I
don't think designing the general mechanism now makes too much sense, we're
likely to get it wrong. :/


>
> >
> >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:
> >
> >   [ui]
> >   chunkselector=text (default)
> >                 curse
> >                 external
> >
> >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.
>
> Thanks,
>
> Laurent
>
> >
> >--
> >Pierre-Yves David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150601/3663c864/attachment.html>