<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body><div>It sounds like this should be added to the GHCi documentation, even if it's not strictly about GHCi.</div><div><br></div><div><br></div><div><br></div><div id="composer_signature"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><div style="font-size:85%;color:#575757">David Feuer</div><div style="font-size:85%;color:#575757">Well-Typed, LLP</div></div><div><br></div><div style="font-size:100%;color:#000000"><!-- originalMessage --><div>-------- Original message --------</div><div>From: Evan Laforge <qdunkan@gmail.com> </div><div>Date: 12/5/17  4:49 PM  (GMT-05:00) </div><div>To: Brandon Allbery <allbery.b@gmail.com> </div><div>Cc: ghc-devs@haskell.org </div><div>Subject: Re: Long standing annoying issue in ghci </div><div><br></div></div>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>https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt<br><br>On Tue, Dec 5, 2017 at 12:57 PM, Brandon Allbery <allbery.b@gmail.com> wrote:<br>> On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <cheater00@gmail.com><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>> allbery.b@gmail.com                                  ballbery@sinenomine.net<br>> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net<br>><br>> _______________________________________________<br>> ghc-devs mailing list<br>> ghc-devs@haskell.org<br>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<br>><br>_______________________________________________<br>ghc-devs mailing list<br>ghc-devs@haskell.org<br>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<br></body></html>