Re: Long standing annoying issue in ghci

2017-12-13 Thread cheater00 cheater00 
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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long standing annoying issue in ghci

2017-12-12 Thread cheater00 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,  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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long standing annoying issue in ghci

2017-12-08 Thread 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, > 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

Re: Long standing annoying issue in ghci

2017-12-07 Thread cheater00 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,  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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long standing annoying issue in ghci

2017-12-07 Thread MarLinn 



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

Re: Long standing annoying issue in ghci

2017-12-05 Thread cheater00 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,  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  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 
>> Date: 12/5/17 4:49 PM (GMT-05:00)
>> To: Brandon Allbery 
>> 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 
>> 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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long standing annoying issue in ghci

2017-12-05 Thread 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  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 
> Date: 12/5/17 4:49 PM (GMT-05:00)
> To: Brandon Allbery 
> 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 
> 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, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long standing annoying issue in ghci

2017-12-05 Thread 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  Date: 
12/5/17  4:49 PM  (GMT-05:00) To: Brandon Allbery  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  wrote:
> On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 
> 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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long standing annoying issue in ghci

2017-12-05 Thread Brandon Allbery 
On Tue, Dec 5, 2017 at 4:49 PM, Evan Laforge  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
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Long standing annoying issue in ghci

2017-12-05 Thread cheater00 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,  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 <
> 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

Re: Long standing annoying issue in ghci

2017-12-05 Thread 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  wrote:
> On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 
> 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, xmonadhttp://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

Re: Long standing annoying issue in ghci

2017-12-05 Thread Brandon Allbery 
On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 
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, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Long standing annoying issue in ghci

2017-12-05 Thread cheater00 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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs