Integrating extensions into core?

Dan Villiom Podlaski Christiansen danchr at
Fri Aug 14 03:57:17 CDT 2009

On 13/08/2009, at 19.03, Brodie Rao wrote:

> I think moving color into ui is the most obvious choice. I think Dan's
> idea of augmenting ui.write() to emit colors is good.

I'm glad you think so!

> I haven't had a chance to look into it deeply, but I imagine you'd
> need to do the following things:
> 1. Take color's smart terminal detection and make sure ui can do the
> same.

I'd say there's more to it than that: ‘color’ doesn't try to do  
anything other than output to a terminal. Furthermore, it does so in  
an awkward way; either by parsing the output of wrapped commands or  
duplicating their functionality. This is both error-prone and  
cumbersome to maintain, and may even corrupt the output as experienced  
by Giorgos Keramidas.

However, if we wish to add proper, integrated support for rich text  
output, some issues arise:

1) What to do when pushing and popping buffers?
2) Should it be possible to override the setting? Permanently?  
Temporarily? Only using derived UI instances?
3) Should the UI offer all possible fundamental text formats, or  
should clients be allowed to add new? (By ‘fundamental text formats’ I  
mean ‘bold’, ‘italics’, ‘normal’ and so on.)
4) Should the UI enforce such a decision, or perhaps require that a  
specified style is actually defined?

> 2. Make --color and --no-color global options. (I'd really like to get
> rid of --no-color, though.)

Perhaps this would be a good occasion for implementing negation of  
boolean options? :)

> 3. Implement something like ui.write(..., color=True).

I know I'm nitpicking, but I don't believe “color” is a good name for  
this argument. (Regardless of whether beige is a colour, bold most  
certainly isn't :P) I'd say ‘style’ should be used for referring to a  
concrete style[1] and perhaps ‘rich’ and ‘plain’ for whether  
formatting should be applied or not.

> #3 raises a couple of questions:
> * How are colors inserted? Templates? %-style expansion?

I'd prefer a one-style-per-call implementation, such as:

   ui.status('Hello World!\n', style='greeting');


   richworld = ui.formatstyle('World', 'emphasis')
   ui.status('Hello %s\n' + richworld)

This allows the original message to be easily readable, and at the  
same time, plain text formatting becomes trivial: ignore the style  
argument.[2] Having style expansion separate from the rest of the UI  
should also improve extensibility and maintainability.

> * How do users of the new API (hg diff, hg qseries, etc.) specify what
> color keys are available and what their default colors are?

The way I see it, the class/module responsible for maintaining and  
defining the rich text would provide an API for adding derivative  
styles. Part of this API would, in my opinion, be to verify that any  
specified style expands to something valid, and to prevent undefined  
or duplicate styles. This is probably a controversial point, but  
please give it a thought! I see several advantages to requiring it:

* The details of how we do will likely be felt by users, increasing  
the importance of reproducibility and consistency.
* Styles are intended to be meaningful and customisable.
* We could list all possible styles, their current values, and a  
perhaps even a description.
* Adding new basic formats or target presenters will be eased by well- 
defined behaviour.

I have some ideas to how this could be implemented that I'd like to  
propose. Before I do that, though, I'd like to hear what you guys  
think of the general approach. Oh, and wouldn't it be great if the  
minirst parser could output rich text on a standard terminal? :)

[1] I had a small argument on IRC with Brodie about this, but I  
suspect “style” is accurate nomenclature here. Besides, it's what  
Apple uses in their word processor, and they know much more about both  
interface design and the English language than I ever will: < 
 >. Perhaps the usual language pedants have an opinion on this?
[2] Apart perhaps, from validation…


Dan Villiom Podlaski Christiansen
danchr at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
Url : 

More information about the Mercurial-devel mailing list