[IPython-dev] bug in coloured prompt

Fernando Perez fperez.net at gmail.com
Sun Apr 1 16:54:20 EDT 2007

On 4/1/07, Thorsten Kampe <thorsten at thorstenkampe.de> wrote:
> * Thorsten Kampe (Wed, 28 Mar 2007 22:30:25 +0100)
> > [IPython 0.7.3 and 0.7.4]
> >
> > Hi,
> >
> > "\#" (maybe other special escapes, too) ignores the colour escape codes
> > in prompts. See for instance [1]. The "\#" is printed in green (although
> > it should be white. Same goes for the out prompt where it's printed in
> > red.
> >
> > Thorsten
> > [1] prompt_in1 '\C_White[\#\C_White]\C_LightCyan>>> '
> Can someone confirm that this is a bug?

Well, it's more of a design limitation, or a not-implemented feature
than a 'oops, little bug we missed' kind of thing.  The original
coloring code, when I wrote it, hardcoded a color scheme for certain
items.  The templates that handle coloring perform this expansion:

    r'\#' : '${self.col_num}' '${self.cache.prompt_count}' '${self.col_p}',

With self.col_num being hardcoded in the color tables defined in
Prompts.py.  These are, at this point, not really user-extensible in
any convenient way.  Having a cleaner way for users to define their
own color schemes is certainly on the ToDo list, and we'll visit it
when we split out the I/O code.

In the meantime, you can work around the problem by using the raw
prompt number object instead of the \# escape:

prompt_in1 '\C_White[${self.cache.prompt_count}\C_White]\C_LightCyan>>> '

self.cache.prompt_count is the prompt counter, so instead of \# you
can abuse the API a little bit this way.

But if you update to SVN, I just added a new prompt escape,


which is identical to \# but does NOT apply any coloring.  Using \N
instead of \# lets you then apply your own colors at will.

While this isn't a real overhaul of the coloring system (we're too
close to a release for that), I think this minimally intrusive change
is sufficient for most purposes, since the prompt number was the only
object that was automatically wrapped in hardcoded coloring.
Technically the entire prompt string gets wrapped also, but that
doesn't matter since the first manually-issued color escape will
override that; the number was problematic because the internal escape
would always win, as you discovered.

I hope this is enough for your needs, since it's as much as I can do
this close to a release.  And thanks for  the report!



More information about the IPython-dev mailing list