[IPython-dev] Re: some trouble with screen formatting in ipython

[Fernando Perez]

Hi,

I've added you to the ipython-dev whitelist, by default non-subscriber posts 
are discarded (too much spam).

ipython-dev-bounces at scipy.net wrote:
> Subject: Re: some trouble with screen formatting in ipython
> From: Dennis Heuer <dh at triple-media.com>
> Date: Fri, 18 Feb 2005 21:50:00 +0000
> To: ipython-dev at scipy.net
> 
> I write to here because I refuse to create the next zillion'st accout for another bugzilla engine (really hate these beasts).
> 
> There was a correspondence with fperez before this mail, which I post first:
> 
> Dennis Heuer wrote:
> 
>>Hello
>>
>>Up to the latest release, ipython produces some errors on my terminal. For
>>example, the 'out' prompt is placed on the center of the line though there
>>is no such hint in the prompt definition. When I define colors for the
>>prompt, they are valid for only the single line that contains the color
>>definition. The next line starts with the default color. The 'history'
>>number appears in green, though -- and it refuses own color settings. When
>>I define: '\C_Red\#', I still get a green number.
>>
>>I've set $TERM to different terminals but without success. The errors
>>appear on both my framebuffer shell and my (native X) nvidia-based
>>gnome-terminal.
> 
> 
> I'm sorry, but I can't reproduce any of this behavior.  Try nuking your ~/.
> ipython directory to start with a fresh one, and see if that helps. Otherwise, 
> please post again to the list, in case a user may have seen in the past 
> something similar and can help.  Also post with detailed system info (OS, 
> python version, ipython version, etc.).
> 
> I've tested with the framebuffer console, xterm, gnome-terminal, KDE's konsole 
> (my normal environment) and an Xemacs shell buffer (which I also use 
> extensively).  They all work as expected, so I'm at a loss to guess what may 
> be going on.
> 
> 
>>And, CTRL-D only quits if the cursor is on a fresh line. Shouldn't it
>>always work?
> 
> 
> No, try it in a plain python prompt and you'll see it's the same as ipython. I 
> can't get the EOF exception from the middle of a line, so there's nothing I 
> can do about it.
> 
> Best,
> 
> fperez
> 
> 
> First to CTRL-D because that's the more simple issue: Is anybody having contacts to the python developers to tell them that the above explained restriction is quite annoying...

If you care about this, you'll have to follow it up yourself.  It's not an 
issue for me, and I am swamped with other things.  Since it's core python 
behavior, I can't deal with it as an ipython-specific bug.

> Second: I nuked ~/.ipython and reinstalled ipython but still have the same trouble. I appended a screenshot for demonstration. The only line of configuration I've changed is the 'in'-prompt definition in ~/.ipython/ipythonrc-pysh:
> 
> prompt_in1 '\C_LightGreen\u@\h\C_LightBlue[\C_LightCyan\Y1\C_LightBlue]\C_Red|\#>'
> 
> As you can see in the screenshot, the # is still green. And, the 'out' prompt appears at the center of the line (it seems to be placed adjusted to the 'in' prompt, but from the right end. I could not find such a flag or prompt definition in the rc files, though).
> 
> Do I have to activate or de-activate something somewhere else?

OK, your screenshot gives much better info.  There's an important difference 
between 'hello' and 'print "hello"'.  The first _returns_ a value, hence there 
is a return prompt.  The second prints to stdout, and does not return anything 
(well, it returns None, technically).  By default, ipython aligns the output 
prompt with the input.  While this may look a little funny in pysh, it looks 
very natural in plain ipython with numbered In/Out prompts.

I'll try to add an option for flush left prompts in a convenient manner, as 
this is a reasonable request.  I'll also allow empty output prompts if you 
want: while I personally don't like this (I like to know the difference 
between a return value --which is cached-- and plain print statements), it's 
up to the users.

As far as the green \#, this is a minor bug of the coloring code due to the 
vagaries of history.   While the color strings allow you to control the 
coloring of most elements, there are a few which are still controlled by the 
old ipython internal coloring code, which only accepts a global 'color scheme' 
choice.  So basically the input/output numbers are hardwired to the choice in 
the color scheme, and there are only 'Linux', 'LightBG' and 'NoColor' schemes 
to choose from.

This is a buglet, but I'm not sure right now I can spend too much time 
clearing it up, as it would basically force a rewrite of much of the prompt 
handling code to abstract out the color management into the prompt definition 
strings.  I've put it on the todo list, but for now I'm afraid that bug stays. 
  Minor as it sounds, a clean fix requires a ton of work.  That code is fairly 
tricky, due to the fact that computing on-screen string sizes with embedded 
color escapes is a bit delicate.

Regards,

f