Thanks Evan, the \STX thing fixed my issue. Much happier now. I'll update the bug and set it to won't fix. On Tue, 5 Dec 2017 22:49 Evan Laforge, wrote:

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

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 Note: If you're using a multi-line prompt, things may be different again. I don't know what the rules are, but I found that if I put \STX on any but the last line of prompts I get weird characters. The same goes for any \SOH you might want to add for some reason.

Cheers, MarLinn

I opened an issue on the Haskeline github (https://github.com/judah/haskeline/issues/72). But it seems to be completely Haskeline-side, so I'm not sure if it's worth re-opening the one for ghci? As missing documentation maybe? (BTW, I found this on the wiki: https://wiki.haskell.org/GHCi_in_colour. Might be a good place to put it, if linked.) If you want to, here are my test cases rewritten as ghci prompts:     -- single line, positioning error :set prompt " \ESC[36m%\ESC[0m " -- single line, works     :set prompt " \ESC[36m\STX%\ESC[0m\STX " -- multiline, bad output     :set prompt "\ESC[32m\STX–––\ESC[0m\STX\n \ESC[36m\STX%\ESC[0m\STX " -- multiline, works but is inconsistent     :set prompt "\ESC[32m–––\ESC[0m\n \ESC[36m\STX%\ESC[0m\STX " In my tests, the positioning errors consistently happen if there are any "unclosed" escape-sequences on the last line of the prompt, regardless of its length. Escape sequences on previous lines consistently create "weird characters", but don't influence the positioning. Also regardless of their lengths. That makes sense, as both sets of lines seem to be handled quite differently. Are multiline prompts even used by a lot of people? I like mine because it gives me a both a list of modules and a consistent cursor position. But maybe I'm the exception? Cheers. On 2017-12-07 23:15, cheater00 cheater00 wrote:

Interesting. Would you mind reopening the issue and providing a buggy example? Amd alerting haskeline maintainers? How does it work on a 1 line prompt that is so long it wraps?

On Thu, 7 Dec 2017 23:11 MarLinn, mailto:monkleyon@gmail.com> wrote:

> 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 Note: If you're using a multi-line prompt, things may be different again. I don't know what the rules are, but I found that if I put \STX on any but the last line of prompts I get weird characters. The same goes for any \SOH you might want to add for some reason.

Cheers, MarLinn

I went ahead and did this for you. On Tue, Dec 12, 2017 at 8:44 PM, cheater00 cheater00 wrote:

Yes, it is worth doing it, because until Haskeline has been fixed and integrated into ghci, the issue persists and needs to remain filed.

On Fri, 8 Dec 2017 18:25 MarLinn, wrote:

...

I opened an issue on the Haskeline github (https://github.com/judah/haskeline/issues/72).

But it seems to be completely Haskeline-side, so I'm not sure if it's worth re-opening the one for ghci? As missing documentation maybe? (BTW, I found this on the wiki: https://wiki.haskell.org/GHCi_in_colour. Might be a good place to put it, if linked.)

If you want to, here are my test cases rewritten as ghci prompts:

-- single line, positioning error :set prompt " \ESC[36m%\ESC[0m " -- single line, works :set prompt " \ESC[36m\STX%\ESC[0m\STX " -- multiline, bad output :set prompt "\ESC[32m\STX–––\ESC[0m\STX\n \ESC[36m\STX%\ESC[0m\STX " -- multiline, works but is inconsistent :set prompt "\ESC[32m–––\ESC[0m\n \ESC[36m\STX%\ESC[0m\STX "

In my tests, the positioning errors consistently happen if there are any "unclosed" escape-sequences on the last line of the prompt, regardless of its length. Escape sequences on previous lines consistently create "weird characters", but don't influence the positioning. Also regardless of their lengths. That makes sense, as both sets of lines seem to be handled quite differently.

Are multiline prompts even used by a lot of people? I like mine because it gives me a both a list of modules and a consistent cursor position. But maybe I'm the exception?

Cheers.

On 2017-12-07 23:15, cheater00 cheater00 wrote:

Interesting. Would you mind reopening the issue and providing a buggy example? Amd alerting haskeline maintainers? How does it work on a 1 line prompt that is so long it wraps?

On Thu, 7 Dec 2017 23:11 MarLinn, wrote:

...

...

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 Note: If you're using a multi-line prompt, things may be different again. I don't know what the rules are, but I found that if I put \STX on any but the last line of prompts I get weird characters. The same goes for any \SOH you might want to add for some reason.

Cheers, MarLinn

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