<p dir="ltr">Thanks Evan, the \STX thing fixed my issue. Much happier now. I'll update the bug and set it to won't fix.</p>
<br><div class="gmail_quote"><div dir="ltr">On Tue, 5 Dec 2017 22:49 Evan Laforge, <<a href="mailto:qdunkan@gmail.com">qdunkan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here's what I use:<br>
<br>
:set prompt "\ESC[46m\STX%s>\ESC[39;49m\STX "<br>
<br>
I believe \STX is a signal to haskeline for control sequences.<br>
Documentation is here:<br>
<a href="https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt" rel="noreferrer" target="_blank">https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt</a><br>
<br>
On Tue, Dec 5, 2017 at 12:57 PM, Brandon Allbery <<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>> wrote:<br>
> On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <<a href="mailto:cheater00@gmail.com" target="_blank">cheater00@gmail.com</a>><br>
> wrote:<br>
>><br>
>> without color coding the prompt so I can't really turn it off. It<br>
>> seems like a simple arithmetic issue somewhere in the readline<br>
>> implementation.<br>
><br>
><br>
> It's not arithmetic except in the sense that it's not doing *any* math.<br>
> Color codes in a terminal are necessarily implemented as character sequences<br>
> (this is pretty much the definition of a terminal interface), and haskeline<br>
> makes no effort to recognize them, so it treats them the same as displayed<br>
> character sequences and skips over them as if they were displayed<br>
> characters.<br>
><br>
> GNU readline handles this by recognizing the character mode sequences as not<br>
> taking up character positions (this is more complex than you think given<br>
> that GNU readline doesn't assume all terminals obey the ANSI standard; as it<br>
> turns out, neither does haskeline, so it actually gets a bit nasty), and<br>
> recognizing the special behavior of carriage return, and providing \[ \]<br>
> escapes to declare the sequence inside as "invisible" to to character<br>
> positioning (and it's on the person crafting the prompt to insure that it<br>
> actually is). Beyond that, it'd actually have to implement a 'terminal<br>
> emulator' internally to get it right in all cases --- and i'd be on the user<br>
> to ensure their declared terminal type matches the actual one well enough<br>
> for the 'terminal emulator' to reflect the terminal's actual behavior, so<br>
> it'd be a potential source of even weirder behavior.<br>
><br>
> So, (a) haskeline issue, not strictly ghc/ghci, and (b) not really fixable,<br>
> but partially work-around-able for common cases.<br>
><br>
> --<br>
> brandon s allbery kf8nh                               sine nomine associates<br>
> <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>                                  <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a><br>
> unix, openafs, kerberos, infrastructure, xmonad        <a href="http://sinenomine.net" rel="noreferrer" target="_blank">http://sinenomine.net</a><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
</blockquote></div>