On Wed, Apr 7, 2010 at 3:31 PM, Stanimir Stamenkov <[email protected]> wrote:
> Tue, 6 Apr 2010 16:48:09 -0500, /Steve Borho/:
>
>> --color is a property of the underlying color extension, and is
>> completely unaffected by wincolor.
>
> But then I haven't enabled the 'color' extension and just the
> 'wincolor' - are they related somehow?
wincolor loads the color extension for you. wincolor simply provides
a filter that converts the ANSI colors into win32 console attributes.
Note that due to (very) recent developments, wincolor will be obsolete
with Mercurial 1.6. The color extension now supports win32 consoles
natively.
tortoisehg unstable nightly builds have have this very soon
>> The color.py logic in hg-1.5.1 looks like this:
>>
>> if (opts['no_color'] or opts['color'] == 'never' or
>> (opts['color'] == 'auto' and (os.environ.get('TERM') == 'dumb'
>> or not sys.__stdout__.isatty()))):
>> "apply color"
>
> Hm, given "(opts['no_color'] or opts['color'] == 'never' or ..."
> shouldn't the last line say "don't apply color"? I guess I have to
> trace somehow at least the results of (os.environ.get('TERM') ==
> 'dumb') and (sys.__stdout__.isatty()) to see if they differ as both
> systems I'm trying on are pretty much the same. The appearance of
> color when '--color always' is specified also indicates the console
> is capable of coloring and sys.__stdout__.isatty() should return
> consistent results.
Are both machines running the same term program?
--
Steve Borho
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Tortoisehg-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
