Bug #53792 for Term-ReadLine-Perl: Prompt with colors gets messed up

On Mon, Jan 18, 2010 at 07:37:43AM -0500, Roland Huss via RT wrote: Show quoted text
Behaves as expected. (But improvements welcome.) Yours, Ilya

Show quoted text
You probably mean 'works as designed' ? Frankly, I would have expected something different (i.e. taking into account 'invisible' character combinations like ANSI Escape sequences in the prompt when redisplaying). Please don't get me wrong, I really love Term::ReadLine::Perl for it's painless multiplatform support (everyboy trying to install Term::ReadLine::Gnu on a stock OS X can confirm this) and I'm consistently surprised about the feature richness of Term::ReadLine::Perl. Chapeu ! And in fact, I looked into the code before opening this ticket but thought you are closer to it as it seems that the code carries quite some 'historical baggage'. (i.e. because you did a release recently) Nevertheless, your answer is clear and I will try to find a patch if I get into it. In the meantime I disable prompt-coloring when using Term::ReadLine::Perl and enable it for Term:ReadLine::Gnu for which prompt-coloring works unexpectedly ;-) Thanks again for this cool module. You can close the ticket, I would then open a new one in case I have a patch.

On Tue, Jan 19, 2010 at 10:04:16AM -0500, Roland Huss via RT wrote: Show quoted text
What happens if you have multiline prompt, and edit multiline input so that part of prompt goes off screen? (This is a functional equivalent of "our" operation...) Ilya

Show quoted text
Sorry, don't know exactly how to do this one. Multi line prompt, ok, but what is required to allow multi-line input. Any options ? Can't find it in the documentation of Term::ReadLine either. I guess, Term::ReadLine::Gnu use 'rl_expand_prompt' for proper prompt handling (though I didn't verify this). From the GNU Readline 6.1 documentation: Function: int rl_expand_prompt (char *prompt) Expand any special character sequences in prompt and set up the local Readline prompt redisplay variables. This function is called by readline(). It may also be called to expand the primary prompt if the rl_on_new_line_with_prompt() function or rl_already_prompted variable is used. It returns the number of visible characters on the last line of the (possibly multi-line) prompt. Applications may indicate that the prompt contains characters that take up no physical screen space when displayed by bracketing a sequence of such characters with the special markers RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE (declared in `readline.h'. This may be used to embed terminal-specific escape sequences in prompts.

On Tue Jan 19 17:01:07 2010, nospam-abuse@ilyaz.org wrote: Show quoted text
For bash this works, but using Term::ReadLine::GNU, I get [osgish] : "Bla Blub need closing quote ["] at char 0: "Bla Blub ^ [osgish] : Show quoted text
Actually I wouldn't mind to put the burden on the user. I.e. she is responsible for mixing in the proper escapes when setting the prompt. Special control characters are interpreted by the backend, which by coincidence could be the same for Term::ReadLine::Gnu and Term::ReadLine::Perl. The frontend Term::ReadLine itself is agnostic to the content of the prompt (as it always was). Alternatively, Term::ReadLine could provide constants on its own (to be respected by the backend) but I guess, this is out of scope as Term::ReadLine is bundled with Perl itself. And in fact, Term::ReadLine::Gnu isn't that smart as I thought first. Color prompting without escaping as described above seems to work, but if one uses the history and comes across an entry which is longer than the prompt itself, then the display gets messed up, too (an additonal length($prompt) offset for the input). However, when I manually put in the escapes as described above ("\01" . YELLOW . "\02") everything works smoothely so far (except that I still wasn't able to check multiline input). bye ... ... roland

On Wed, Jan 20, 2010 at 05:23:43PM -0500, Ilya Zakharevich via RT wrote: Show quoted text
In fact, having 2 bracketing characters would not work with TRlP. The prompt may be substr()inged; so we need "0-length stuff which sticks left" (as in "end highlighting"), and "0-length stuff which sticks right" (as in "start highlighting"). Yours, Ilya

On Wed Jan 20 17:23:42 2010, nospam-abuse@ilyaz.org wrote: Show quoted text
You are right, that the perfect solution where a user can semantically manage an *already* set RL prompt is really a heroic task (as you give in your examples). My assumption however was that for by far the most use cases the user is in complete control of the prompt and only sets this in TRl and never read it back. Within this model, he can prepare the prompt in a concise form for the specific backend in use. He is also responsible for the proper bracket alignment and can decided on it's own, which characters should be of 0-length. In my naive view, a TRl backend only needs to take into account the markers and rely on a proper alignment as set by the client. The backend, though, needs to keep track about the brackets. If I understand right, you suggest to keep two copies of the prompt, the original one and a 'clean' version on which text manipulations are done. The challenge here is to keep track between the corresponding printable characters in both versions of the prompt. But where, except for multi line prompts, do you need text manipulations for prompt handling ? (BTW, for multi-line prompts wouldn't it be nicer if Term::ReadLine::prompt() would be able to be called with an arrayref ?) Arghh. Never thought that terminal control is such a hard stuff. For sure, this discussion here increased my (even already high) respect for Term::ReadLine and its various backends ... ;-) Thanks a lot. ...roland

Thanks for your efforts. For me the current situation is perfectly ok, I can live without a colored prompt in TRP (although it would be nice, too :) To avoid misunderstandings, by "user" I meant the 'user' of the module (i.e. a script), not the end-user (so, the script using TR has control over the prompt and 'owns' it. That's true at least for my own scripts). Thanks again, let me know, when I can help testing sth. Or maybe (but unlikely) I have time to dive into the control character hell, too ;)