Unreasonable line-editor behaviour

Summary

The line-editor used in GHCi is unusably broken.

Steps to reproduce

Run GHCi, then type abc and press Ctrl+A (or the Home key). The visible cursor will now be over the c. Pressing the right arrow key three times moves the visible cursor far beyond the visible text. Repeating this process will continually shift rightward the position that the line-editor sees as the beginning of the line. The cursor location and the visible text are out of sync.

Expected behavior

The press of Ctrl+A should result in the cursor moving to the beginning of the line, rather than just one character to the left of where it was.

Environment

• GHC version used: 8.10.5

Optional:

• Operating System: macOS 11.3
• System Architecture: arm64

added needs triage label

a workaround for now seems to be invoking GHCi as TERM=dumb ghci

I can't reproduce this. Which terminal emulator and operating system are you using?

Apple's Terminal.app, macOS 11.3 using the newly-released GHC 8.10.5 — Apple Silicon (arm64 / aarch64) version. The x86_64 version is unaffected.

I see the "info needed" tag persists: what more can I offer?

The Haskeline line editor repository has an issue opened (by someone other than myself) for exactly the same issue: https://github.com/judah/haskeline/issues/162

I am unsure which side is responsible: Is it the new Arm NCG doing strange things? Is it the Haskeline library itself misbehaving due to system-specific issues? vttest shows the terminal working as expected.

removed needs triage label

added info needed label

added GHCi label

added developer experience label

added Tbug label

@bgamari Could this be another FFI issue?

@vvulpes0 There is a blogpost here which will be published soon to explain the issue - homepage!86 (merged)

added aarch64-darwin label

This post on Reddit seems like another manifestation of this. The info needed label is probably not relevant.

UPD the reddit author says he can't reproduce this one.

@vvulpes0 can you try to reproduce your report with GHC 8.10.7?

Indeed, this behaviour persists in the current 8.10.7 build. I've been satisfied using TERM=dumb ghci to work around it though.

I'm attaching three documents here, each produced by script and containing control sequences. In all cases, the input is "test", then Ctrl+A, then print . The first, ghci.txt, is the default settings. The second, ghci-dumb.txt, is from TERM=dumb ghci. The difference seems to be that the dumb terminal uses backspace characters for the Ctrl+A, while the default settings use CSI 0 D, which is equivalent to a single press of the left arrow key. Finally there is ghci-x64.txt, from a non-arm machine which is running 9.0.1, where the presented sequence is CSI 6 D, equivalent to the expected six presses of the left arrow key.

There is a yet-unmerged pull-request in the Haskeline repository that claims to fix this. Yet another instance of ccall vs capi, this time with respect to the tparm function (which makes sense, CSI Ps D is a parameterized string).

ghci.txt ghci-dumb.txt ghci-x64.txt

update: it has now been merged and terminfo-0.4.1.5 released. a fresh build of GHC 8.10.7 with the new terminfo package works as expected

mentioned in issue #20537

closed

removed info needed label

changed milestone to %8.10.7

Also facing weird behavior in Apple Terminal.app when trying to edit / list REPL history. When using arrows to move cursor or deleting chars it appends edited input to current input string.
Example:

1. type :t (+)
2. press Enter
3. press Up arrow to bring back from history previous input.
   Shows: :t (+)|, where | shows cursor
4. press Left arrow twice Cursor moves onto +: :t (|+)
5. press backspace to delete ( Showing correct string: :t +|), but cursor moved right
6. pressing Left arrow moves cursor again on +,
7. next, typing ( gives completely wrong results :t ( +|), insert extra whitespace, moves cursor right again

• macOS Menterey 12.1
• Apple M1 chip

Following Dakotah's Lambert suggestion and setting TERM to DUMB fixes this issue. It's very odd, but shell complains about TERM value:

warning: Could not set up terminal.
warning: TERM environment variable set to 'DUMB'.
warning: Check that this terminal type is supported on this system.
warning: Using fallback terminal type 'ansi'.
warning: Could not set up terminal.
warning: TERM environment variable set to 'DUMB'.
warning: Check that this terminal type is supported on this system.
warning: Using fallback terminal type 'ansi'.

but if I set TERM to ansi manually issue persists.

Check the terminfo version you're using. I believe the shipped builds still use the older one, but rebuilding against 0.4.1.5 works great for me

mentioned in issue #20722

I installed GHC from pre-built binaries and am running into this issue. Do I really need to rebuild GHC to fix the problem? I'm surprised that doing so would make a difference: the behavior of the built GHC shouldn't depend (I think) on what libraries I have installed on my local system.

Or is it possible to update the posted binary on the GHC server? If I understand the discussion here correctly, we currently have a binary listed at https://www.haskell.org/ghc/download_ghc_8_10_7.html which isn't fully usable. (Also, that page seems to support only x86-64 at first -- only by scrolling down do we see support for M1.)

Or maybe I'm misunderstanding the fix.

Indeed, the prebuilt binary is built against the earlier version of the library. I needed to build a fresh compiler against the newer version in order for it to work.