Long standing annoying issue in ghci

[David Feuer]

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


David FeuerWell-Typed, LLP
-------- Original message --------From: Evan Laforge <qdunkan at gmail.com> Date: 12/5/17  4:49 PM  (GMT-05:00) To: Brandon Allbery <allbery.b at gmail.com> Cc: ghc-devs at 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 <allbery.b at gmail.com> wrote:
> On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <cheater00 at 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 at gmail.com                                  ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171205/70d394b9/attachment.html>