Long standing annoying issue in ghci

[Brandon Allbery]

It's indirectly already there:
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#the-ghci-and-haskeline-files
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 <david at well-typed.com> 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 <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
>



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171205/9130e48a/attachment.html>