Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mpilgrem
Copy link

@mpilgrem mpilgrem commented Dec 8, 2019

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 mpilgrem changed the title Fix #88 Don't skip "\ESC...\STX" sequences (when terminal-style) Fix #130 Don't skip "\ESC...\STX" sequences (when terminal-style) Dec 30, 2019
@mpilgrem mpilgrem force-pushed the fix88 branch 3 times, most recently from ccdf279 to b564d7a Compare August 20, 2022 22:36
For ANSI-capable terminals, 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).

It uses the same logic as the ansi-terminal package to determine if the terminal is ANSI-capable.
@mpilgrem
Copy link
Author

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
Copy link

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.

image

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

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants