[PATCH] ui: add new config flag for interface selection
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
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
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:
Yuya proposal is:
I prefer new section rather than putting everything under pseudo
(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:
(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
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
That will not be too noisy. On the other hand a dedicated section with
only 1 value used in most case might look silly.
(and I probably committed a couple of these silly section already :-/)
(2) Config Values
A debate sparkled around using "crecord" or "curse" as value.
(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,
- thg (the text version!)
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.
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.
More information about the Mercurial-devel