Re: Long standing annoying issue in ghci

A simple example of colored prompt would be good enough, so as not to make the docs too huge. People will be able to figure out they need \STX, or just make sure to tell them. On Tue, 5 Dec 2017 23:17 Brandon Allbery, wrote:

It's indirectly already there: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#th... Possibly an additional pointer needs to be in the FAQ/things to watch out for section.

On Tue, Dec 5, 2017 at 5:13 PM, David Feuer wrote:

...

It sounds like this should be added to the GHCi documentation, even if it's not strictly about GHCi.

David Feuer Well-Typed, LLP

-------- Original message -------- From: Evan Laforge Date: 12/5/17 4:49 PM (GMT-05:00) To: Brandon Allbery Cc: ghc-devs@haskell.org Subject: Re: Long standing annoying issue in ghci

Here's what I use:

:set prompt "\ESC[46m\STX%s>\ESC[39;49m\STX "

I believe \STX is a signal to haskeline for control sequences. Documentation is here: https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt

On Tue, Dec 5, 2017 at 12:57 PM, Brandon Allbery wrote:

...

On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 < cheater00@gmail.com> wrote:

...

without color coding the prompt so I can't really turn it off. It seems like a simple arithmetic issue somewhere in the readline implementation.

It's not arithmetic except in the sense that it's not doing *any* math. Color codes in a terminal are necessarily implemented as character sequences (this is pretty much the definition of a terminal interface), and haskeline makes no effort to recognize them, so it treats them the same as displayed character sequences and skips over them as if they were displayed characters.

GNU readline handles this by recognizing the character mode sequences as not taking up character positions (this is more complex than you think given that GNU readline doesn't assume all terminals obey the ANSI standard; as it turns out, neither does haskeline, so it actually gets a bit nasty), and recognizing the special behavior of carriage return, and providing \[ \] escapes to declare the sequence inside as "invisible" to to character positioning (and it's on the person crafting the prompt to insure that it actually is). Beyond that, it'd actually have to implement a 'terminal emulator' internally to get it right in all cases --- and i'd be on the user to ensure their declared terminal type matches the actual one well enough for the 'terminal emulator' to reflect the terminal's actual behavior, so it'd be a potential source of even weirder behavior.

So, (a) haskeline issue, not strictly ghc/ghci, and (b) not really fixable, but partially work-around-able for common cases.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs