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