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 <da...@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 <qdun...@gmail.com> > Date: 12/5/17 4:49 PM (GMT-05:00) > To: Brandon Allbery <allber...@gmail.com> > 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 <allber...@gmail.com> > wrote: > > On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 < > cheate...@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 > > allber...@gmail.com > ballb...@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 allber...@gmail.com ballb...@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
