Fix #130 Don't skip "\ESC...\STX" sequences (when terminal-style)

[mpilgrem]

This reverses commit f827f10 of 11 September 2010 (about 5 years before the November 2015 Update to Windows 10 made the native consoles on Windows 10 ANSI-capable). Applications like GHCi and stack enable the ANSI-capability of the native consoles.

In respect of legacy Windows, none of them have mainstream support by Microsoft and Windows 7 loses extended support on 14 January 2020.

It has been tested on Windows 10 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

[mpilgrem]

I have taken a different approach to my original pull request. I use the same logic as in the ansi-terminal package to detect if the Windows terminal is ANSI-capable or not. If not ANSI-capable, the existing code is retained.

It has been tested on Windows 11, with the same example code as above. As in the case of ansi-terminal, I am unable to test the logic on machines without an ANSI-capable terminal as I no longer have access to machines with legacy Windows.

[ChrisPenner]

Hrmm, I tested 3b26f1e on my Windows 11 VM via Parallels and got the following result, note how the ANSI in the prompt isn't being interpreted.

However, the simple revert of the original change, d6c2643b0d5c19be7e440615c6f84d603d4bc648, seems to behave as intended:

[simonmichael]

Status update: @athas has expressed willingness to consider this once it is updated and a windows user has vouched for it.

[mpilgrem]

To start with, I have:

• rebased my 20 Aug 2022 approach; and
• tested that it still works, on Windows 11 Version 24H2/x86_64 in:
  • Windows Terminal 1.22.12111.0 (in both PowerShell and Command Prompt tabs); and
  • conhost.exe cmd.exe EDIT: Strike that; I was running that in the Stack environment, where ANSI-capability was already enabled.

As in 2022, I don't have access to legacy Windows machines to test.

However:

• ansi-terminal-1.0 (released 13 May 2023) dropped support for legacy Windows requiring emulation. That package itself takes a very conversative approach to backwards compatibility.
• in August 2025, I would support my original approach in December 2019 of simply reverting commit f827f10. I am assuming that very few Windows users of Haskell are using conhost.exe cmd.exe.

[athas]

Does that mean you suggest we revert f827f10 instead of merging this PR?

I have no opinion on or knowledge of the terminal situation on Windows, so I am willing to go with whatever you consider best.

[mpilgrem]

@athas, in short 'yes'.

I think the situation for Windows users (of which I am one) is this:

• native terminals on Windows 10 and 11 have been ANSI-capable for a long time now (non-native terminals are also ANSI-capable and ANSI-enabled);
• Windows Terminal is the default native terminal on Windows 11 and can be set as the default on Windows 10 (since Windows 10 22H2);
• Windows Terminal is ANSI-enabled by default;
• the legacy conhost.exe cmd.exe is ANSI-capable but not ANSI-enabled by default (for backwards compatability reasons): an application has to enable ANSI-capability; and
• I think it very unlikely that anybody is still using conhost.exe cmd.exe in practice. On Windows 11, it is hard to find. Windows Terminal provides cmd.exe in a Command Prompt tab (that is ANSI-enabled).

(I think the problem with my 20 August 2022 patch is that I was not enabling ANSI early enough.)

I think:

• it would be reasonable for the haskeline package to drop support for conhost.exe cmd.exe; but
• if it wanted to allow users of haskeline to support users of conhost.exe cmd.exe (their choice), it could provide a function (say, enableAnsiSupport :: InputT m Bool) that would do nothing on non-Windows operating systems but would attempt to enable ANSI on Windows systems. Personally, I doubt if there is any meaningful demand for that support.

EDIT: If there is an interest in the last bullet point above, I have an alternative pull request that implements it. Users on Windows would have code like:

module Main where

import Control.Monad ( when )
import System.Console.Haskeline

main :: IO ()
main = do
  runInputT defaultSettings $ do
    -- Test needed only if necessary to support users of conhost.exe
    isAnsiSupported <- enableAnsiSupport
    when isAnsiSupported 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

[athas]

If you make a PR that reverts that commit, then I will merge it. While I'm reluctant to make opinionated changes to Haskeline, I prefer supporting recent Windows users over ancient Windows users.

[mpilgrem]

@athas, now done.

[athas]

Could you also update the Changelog? This is after all a user-visible change.

[mpilgrem]

@athas, happy to do that and also done.