ANSI sequenced in GHCi prompt work only when \n is present in line

[cpkio]

I found this link over internet and think there's a bug somewhere here: https://github.com/judah/haskeline/blob/3bf2b621685fc795f0dc3f3196728ccea492d42b/System/Console/Haskeline/LineState.hs#L109

I've tested almost everything with my new 8.4.3 Haskell installation on Windows 10 and it seems that \ESC[ color sequence works only when \n finishes the line; in any other situation (if you want to color the prompt without \n ending) the ghci prompt outputs the ANSI sequence text as it is and does not color the string.

[cpkio]

sorry, misposted

[mpilgrem]

Perhaps this issue could be re-opened, as it is a current issue with haskeline-0.7.5.0 on Windows 10. (I also thought, initially, that it was a GHCi 8.6.5 or 8.8.1 issue - https://gitlab.haskell.org/ghc/ghc/issues/17512.)

The native consoles on Windows 10 are ANSI-capable, and there is no longer any version of Windows that has mainstream support by Microsoft that is not ANSI-capable, although ANSI-capability needs to be 'turned on' because of backwards compatibility with consoles on legacy Windows. I think GHCi and stack exec -- [command] turns it on.

A little knowledge is a dangerous thing, but when I disabled fixEsc in drawLineDiff (in module System.Console.Haskeline.Backend.Win32) as follows:

let fixEsc = id -- was: filter ((/= '\ESC') . baseChar)
in  drawLineDiffWin (fixEsc xs1, fixEsc ys1) (fixEsc xs2, fixEsc ys2)

then haskeline worked as expected. I tested it with:

module Main where

import System.Console.Haskeline

main :: IO ()
main = runInputT defaultSettings loop
 where
  prompt = "\ESC[34m\STXBlue\ESC[39m\STX\n\ESC[31m\STXRed\ESC[39m\STX: "
  loop :: InputT IO ()
  loop = do
    minput <- getInputLine prompt
    case minput of
      Nothing -> pure ()
      Just "quit" -> pure ()
      Just input -> do outputStrLn $ "Input was: " ++ input
                       loop

[judah]

Thanks @mpilgrem. What you're describing appears to be a separate issue than this bug, so I've split it out into #130.