Long standing annoying issue in ghci

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Long standing annoying issue in ghci

cheater00 .
Hi guys, this one seems to have gotten buried under more important
things, but maybe someone would like to take a look at it none the
less? I've been encountering it literally every day for the last 4
years. I sometimes find it difficult to find read the past commands
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.

https://ghc.haskell.org/trac/ghc/ticket/9364

Thanks a lot.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

Brandon Allbery
On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

Evan Laforge
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 <[hidden email]> wrote:

> On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <[hidden email]>
> 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
> [hidden email]                                  [hidden email]
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

cheater00 .

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, <[hidden email]> 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 <[hidden email]> wrote:
> On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <[hidden email]>
> 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
> [hidden email]                                  [hidden email]
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

Brandon Allbery
In reply to this post by Evan Laforge
On Tue, Dec 5, 2017 at 4:49 PM, Evan Laforge <[hidden email]> wrote:
I believe \STX is a signal to haskeline for control sequences.
Documentation is here:
https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt

Huh, so they did add support for that. With a version constraint, so this will depend also on haskeline version (and therefore ghc version, and what works in newer ghci will therefore not work in older ones).

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

David Feuer-2
In reply to this post by cheater00 .
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 <[hidden email]>
Date: 12/5/17 4:49 PM (GMT-05:00)
To: Brandon Allbery <[hidden email]>
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 <[hidden email]> wrote:

> On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <[hidden email]>
> 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
> [hidden email]                                  [hidden email]
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

Brandon Allbery
In reply to this post by cheater00 .
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 <[hidden email]> 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 <[hidden email]>
Date: 12/5/17 4:49 PM (GMT-05:00)
To: Brandon Allbery <[hidden email]>
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 <[hidden email]> wrote:

> On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <[hidden email]>
> 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
> [hidden email]                                  [hidden email]
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

cheater00 .

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, <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]>
Date: 12/5/17 4:49 PM (GMT-05:00)
To: Brandon Allbery <[hidden email]>
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 <[hidden email]> wrote:

> On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 <[hidden email]>
> 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
> [hidden email]                                  [hidden email]
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

MarLinn
In reply to this post by Evan Laforge

> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

cheater00 .

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, <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

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, <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

cheater00 .

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, <[hidden email]> 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, <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Long standing annoying issue in ghci

cheater00 .
I went ahead and did this for you.

On Tue, Dec 12, 2017 at 8:44 PM, cheater00 cheater00
<[hidden email]> 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, <[hidden email]> 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, <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs