[PATCH] ui: add new config flag for interface selection

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Jan 7 14:18:06 CST 2016



On 12/23/2015 05:30 AM, Laurent Charignon wrote:
> # HG changeset patch
> # User Laurent Charignon <lcharignon at fb.com>
> # Date 1450848537 28800
> #      Tue Dec 22 21:28:57 2015 -0800
> # Node ID 3e4f77c0bd16c78f2de991b483325eef1dc6f3fb
> # Parent  fe376159a58d9b3d748b669ac011b0eed0346fea
> ui: add new config flag for interface selection
>
> This patch introduces a new config flag ui.interface to select the interface
> for interactive commands. It currently only applies to chunks selection.
> The config can be overridden on a per feature basis with the flag
> ui.interface.<feature>.

I noted 3 points raised in various people replies

1) In what section to put this code.

2) What should the config value be

3) What happen when the specified value is unknown.

Given that Laurent have been talking about this for months and send 
details on his plan a descent amount of time ahead of this series. I 
would be fairly disappointed if we can't allow him to land that before 
the freeze.

While we discuss this points, I'm tempted to move forward with Laurent 
code and proposal. Making changes to it as we get consensus on the above 
questions. What do you thinks?


(1) What config section to use
------------------------------

Laurent proposal is:

   [ui]
   interface=
   interface.subtype=

Yuya proposal is:

   [interactive-ui]

Yuya's Rational:

   I prefer new section rather than putting everything under pseudo 
'ui.interface.'

[my opinion]

(I've a mild opinion about this. I've some preference but won't see a 
different direction as problematic.)

a) We'll have sub values anyway. I expect people to want to configure 
value on a command basic and etc. so we'll end up with things like:

ui.interface.hunkselector.commit=foo
ui.interface.hunkselector.split=bar

(or something different, but still subvalued, see merge-tools)

(We are not planning to support this in the initial implementation. But 
change are quite high that people will ask for it so better keep room 
for that).

b) for a change, what we would like put "ui" is exactly about "user 
interface" (and not about default value and behavior). It would be quite 
a shame to not use the UI config section for a UI stuff.

c) I expect most users to just set it once for the top level

   [ui]
   interface=curse

That will not be too noisy. On the other hand a dedicated section with 
only 1 value used in most case might look silly.

   [interactive-ui]
   default=curse

(and I probably committed a couple of these silly section already :-/)


(2) Config Values
------------------

A debate sparkled around using "crecord" or "curse" as value.

[My opinion]

(I've a stronger opinion here but, as usual, perfectly open to 
adjustement, or counter proposal taking concerns into account)

We should use both. We currently have 1 curse UI for 1 command (2 if you 
count chistedit). but we will get many of them for many commands, 
eventually even multiple proposals using curse for the same command. 
Curse is a plateform not a UI. We should be ready for that.

I can see 4 general categories of UI:

- test (like current record),
- curse (like current crecord),
- editor (like current histedit),
- gui (like gui-merge for example).

(+ other I can't see but people will come with)

Each of this will eventually get multiple incarnation (and each 
incarnation will maybe get variant?)

I can imagine we'll eventually end up with a tree in the spirit of this

- auto: take "best" available one,
   - curse:
     - crecord:
     - compact:
     - thg (the text version!)
   - editor:
     - histeditdropmissing
   - gui:
     - thg:
     - qtcommit


So I think, we should use "curse" as the top level one, used as a 
synonyms for "the best available curse UI we ship".

(Again, we are not planning to support this in the initial 
implementation. But change are quite high that people will ask for it so 
better keep room for that).



(3) What happen when the
------------------------

There is a debate around what to do when the specified value is invalid. 
Should we abort or fallback to the default value with a warning.

[my opinion]

I don't have a strong opinion about this, and there is probably a 
direction that is position it is easy to move from in the future if we 
are unhappy about our choice. This also seems small enough to be changed 
sometime between the freeze and release.

We'll have "valid but unusable" value anyway. Stuff like uninstalled 
tool, or unavailable curse, or non-tty automation. I think it make sense 
to fall back to the default in that case with a warning.


-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list