Backspace, delete, etc. don't work in ghci in HEAD

changed weight to 5

By the way, xev says my backspace key is sending keycode 22/keysym 0xff08/BackSpace, and the delete key is sending keycode 107/keysym 0xffff/Delete. Obviously all the keys work in ghci 6.8.2 and in other apps.

Do you reproduce the bug by opening up an xterm, and then typing 'ghci'? If so, what happens when you type "stty -a" in the xterm? Alternately, if you start ghci in such a way as to reproduce the bug, what happens when you run the following commands from inside ghci:

System.IO.hIsTerminalDevice System.IO.stdin
System.IO.hIsTerminalDevice System.IO.stdout
System.Environment.getEnv "TERM"

Finally: what version of libedit are you building against?

I suspect that some part of your xterm configuration is not set quite right, causing libedit to think that it's not inside a terminal. But it's strange that readline (used in ghc-6.8.2) isn't affected.

Replying to [ticket:2606#comment:25911 judah]:

Do you reproduce the bug by opening up an xterm, and then typing 'ghci'? If so, what happens when you type "stty -a" in the xterm?

Yes. "stty -a" says:

speed 38400 baud; rows 41; columns 89; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>;
swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc
-ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

If I enter ghci, hit Ctrl-Z, and bring it back in the foreground so the keys start working again, and then type :!stty -a, the output looks exactly the same to me as before entering ghci.

Alternately, if you start ghci in such a way as to reproduce the bug, what happens when you run the following commands from inside ghci:

{{{ System.IO.hIsTerminalDevice System.IO.stdin

True

System.IO.hIsTerminalDevice System.IO.stdout

True

System.Environment.getEnv "TERM"

"xterm"

The values for these are the same both while the bug is exhibiting itself, and after suspending and re-activating ghci.

Finally: what version of libedit are you building against?

$ ls -lh /usr/lib/libedit.*
lrwxrwxrwx 1 root root   14 2008-08-02 23:20 /usr/lib/libedit.so.2 -> libedit.so.2.9
-rw-r--r-- 1 root root 106K 2007-04-27 09:39 /usr/lib/libedit.so.2.9

and I don't have any other versions floating around.

I've never had problems with key mappings on this computer that I can recall, except for now with the HEAD.

Replying to [ticket:2606#comment:25912 tim]:

Replying to [ticket:2606#comment:25911 judah]:

Do you reproduce the bug by opening up an xterm, and then typing 'ghci'? If so, what happens when you type "stty -a" in the xterm?

Yes. "stty -a" says: (...)

If I enter ghci, hit Ctrl-Z, and bring it back in the foreground so the keys start working again, and then type :!stty -a, the output looks exactly the same to me as before entering ghci.

Just to clarify: what happens when you type :!stty -a from inside ghci immediately after entering ghci?

I've never had problems with key mappings on this computer that I can recall, except for now with the HEAD.

I suspect this is a problem with libedit, since HEAD replaced readline with it it between 6.8 and 6.10. Do you know of any other programs on your machine that use libedit and whether they have the same issue? Otherwise, would it be possible for you to compile the following C program (with gcc -ledit) and check its behavior inside the xterm?

#include <stdio.h>
#include <editline/readline.h>

int main(void) {
    char *result;
    rl_initialize();
    result = readline("enter:");
    printf("%s\n",result);
    return 0;
}

Replying to [ticket:2606#comment:25955 judah]:

Just to clarify: what happens when you type :!stty -a from inside ghci immediately after entering ghci?

Still the same output as what I pasted.

I suspect this is a problem with libedit, since HEAD replaced readline with it it between 6.8 and 6.10. Do you know of any other programs on your machine that use libedit and whether they have the same issue? Otherwise, would it be possible for you to compile the following C program (with gcc -ledit) and check its behavior inside the xterm?

Done (I had to install libedit-dev first, but I don't think that had any other effects); your test program works fine (backspace, delete, Ctrl-U) work, when it's run in an xterm, but still the same problem with ghci.

Hmm, if you had to install libedit-dev to build that program then maybe ghc's editline bindings weren't built when you built ghc. Can you please check whether ghc's editline package is installed, for example by:

trying to run :browse System.Console.Editline.Readline inside ghci
double-checking whether the up/down arrow keys page through the ghci history If it's not installed, you can probably fix this problem by building ghc again.

Replying to [ticket:2606#comment:25961 judah]:

Hmm, if you had to install libedit-dev to build that program then maybe ghc's editline bindings weren't built when you built ghc. Can you please check whether ghc's editline package is installed, for example by:

trying to run :browse System.Console.Editline.Readline inside ghci

double-checking whether the up/down arrow keys page through the ghci history

If it's not installed, you can probably fix this problem by building ghc again.

Indeed, the browse command you suggested says there's no such module, and the arrow keys don't work (even after I suspend ghci and bring it back to the foreground as I described before). So I think your explanation is probably right. I won't have a chance to build ghc again for a little bit, but I think it should really be documented that you need to install the libedit-dev package (or whatever the equivalent is for distros other than Ubuntu/Debian), because my install of Ubuntu didn't come with it by default and I would expect that either this would work out of the box, or configure would tell me that I lacked a needed dependency.

Replying to [ticket:2606#comment:25961 judah]:

Hmm, if you had to install libedit-dev to build that program then maybe ghc's editline bindings weren't built when you built ghc. Can you please check whether ghc's editline package is installed, for example by:

trying to run :browse System.Console.Editline.Readline inside ghci

double-checking whether the up/down arrow keys page through the ghci history

If it's not installed, you can probably fix this problem by building ghc again.

It's also missing in my case, additionally it seems that readline is the only one of the darcs packages missing at the source distributions (6.10,6.11) - might this problem be nonexistent if building from darcs? What's the reason to omit readline?

Replying to [ticket:2606#comment:29355 dorinho]:

Replying to [ticket:2606#comment:25961 judah]:

Hmm, if you had to install libedit-dev to build that program then maybe ghc's editline bindings weren't built when you built ghc. Can you please check whether ghc's editline package is installed, for example by:

trying to run :browse System.Console.Editline.Readline inside ghci

double-checking whether the up/down arrow keys page through the ghci history

If it's not installed, you can probably fix this problem by building ghc again.

It's also missing in my case, additionally it seems that readline is the only one of the darcs GHC boot packages missing at the source distributions (6.10,6.11) - might this problem be nonexistent if building from darcs? What's the reason to omit readline?

In 6.10 ghci uses the editline (libedit) package instead of readline, so only the former is distributed by default. The readline package can still be downloaded from hackage.haskell.org if needed.

In order to get the rich line-editing interface you need to have the libedit library installed before building ghc; see Building/Prerequisites for more information.

Replying to [ticket:2606#comment:29361 judah]:

In 6.10 ghci uses the editline (libedit) package instead of readline, so only the former is distributed by default. The readline package can still be downloaded from hackage.haskell.org if needed.

In order to get the rich line-editing interface you need to have the libedit library installed before building ghc; see Building/Prerequisites for more information.

:-) Meanwhile, I am using HEAD in darcs (6.11.20081009) and added the libedit-dev package to (x)ubuntu. It seems to work - thank you very much!

closed

Looks to me like this turned out to be behaving as expected, then. Thanks for tracking it down, guys!

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedInvalid

For fedora it turned out problem was that ncurses-devel was needed for editline to configure correctly.

ctrl-<left arrow> does not work. #2741 (closed) lists a hacky solution for delete. Is there a solution for the rest of they key bindings? ghci-haskeline makes no visible difference in the behavior.

$ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> should move one word back;5D

$ uname -a Linux XXXXXXX 2.6.23.17-88.fc7 #1 (closed) SMP Thu May 15 00:02:29 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

$ stty -a speed 38400 baud; rows 24; columns 136; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

Prelude> System.IO.hIsTerminalDevice System.IO.stdin True Prelude> System.IO.hIsTerminalDevice System.IO.stdout True Prelude> System.Environment.getEnv "TERM" "xterm"

$ ls -lh /usr/lib/libedit.* lrwxrwxrwx 1 root root 17 2009-01-29 19:15 /usr/lib/libedit.so -> libedit.so.0.0.26 lrwxrwxrwx 1 root root 17 2009-01-29 16:56 /usr/lib/libedit.so.0 -> libedit.so.0.0.26 -rwxr-xr-x 1 root root 149K 2007-11-04 04:31 /usr/lib/libedit.so.0.0.26 $ ls -lh /usr/lib64/libedit.* lrwxrwxrwx 1 root root 17 2009-01-29 19:15 /usr/lib64/libedit.so -> libedit.so.0.0.26 lrwxrwxrwx 1 root root 17 2009-01-29 16:55 /usr/lib64/libedit.so.0 -> libedit.so.0.0.26 -rwxr-xr-x 1 root root 167K 2007-11-04 04:28 /usr/lib64/libedit.so.0.0.26

ghci performs fine in emacs

The C program does not recognize ctrl+<left arrow>

:browse System.Console.Editline.Readline and ghci history work fine

Trac metadata

Trac field	Value
Version	6.9 → 6.10.1
Architecture	x86 → x86_64 (amd64)

reopened

(Sorry, meant to his "preview")

ctrl-<left arrow> does not work. #2741 (closed) lists a hacky solution for delete. Is there a solution for the rest of the usual key bindings? ghci-haskeline makes no visible difference in the wonky behavior.

$ ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude> should move one word back;5D

$ uname -a
Linux XXXXXXX 2.6.23.17-88.fc7 #1 SMP Thu May 15 00:02:29 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

$ stty -a
speed 38400 baud; rows 24; columns 136; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

Prelude> System.IO.hIsTerminalDevice System.IO.stdin
True
Prelude> System.IO.hIsTerminalDevice System.IO.stdout
True
Prelude> System.Environment.getEnv "TERM"
"xterm"

$ ls -lh /usr/lib/libedit.*
lrwxrwxrwx 1 root root   17 2009-01-29 19:15 /usr/lib/libedit.so -> libedit.so.0.0.26
lrwxrwxrwx 1 root root   17 2009-01-29 16:56 /usr/lib/libedit.so.0 -> libedit.so.0.0.26
-rwxr-xr-x 1 root root 149K 2007-11-04 04:31 /usr/lib/libedit.so.0.0.26
$ ls -lh /usr/lib64/libedit.*
lrwxrwxrwx 1 root root   17 2009-01-29 19:15 /usr/lib64/libedit.so -> libedit.so.0.0.26
lrwxrwxrwx 1 root root   17 2009-01-29 16:55 /usr/lib64/libedit.so.0 -> libedit.so.0.0.26
-rwxr-xr-x 1 root root 167K 2007-11-04 04:28 /usr/lib64/libedit.so.0.0.26

ghci performs fine in emacs

The C program does not recognize ctrl+<left arrow>

:browse System.Console.Editline.Readline and ghci history work fine

Trac metadata

Trac field	Value
Resolution	ResolvedInvalid → Unresolved

Let me address each of those problems separately:

Ctrl-<arrow> doesn't work

Both editline and haskeline have ways to be told about ctrl-<arrow>.

For ghci-haskeline, instructions to add ctrl-<arrow> are at: http://trac.haskell.org/haskeline/wiki/CustomKeyBindings

For the standard ghci with editline, you should add the following to your .editrc file:

bind "\e[1;5D" vi-prev-word
bind "\e[1;5C" vi-next-word

where the key sequence might need to be replaced depending on your terminal.

The delete key doesn't work

I agree that the delete behavior in editline is problematic; there's no really satisfying fix short of improving or replacing that library. But <delete> *should* work in ghci-haskeline. If it doesn't, can you please do the following:

Type ghc -e getLine, press delete and then return to see the control sequence for the delete key.
Type infocmp and paste the line with the kdch1 entry.

I was looking at a bad copy of ghci-haskeline. Delete does work in it.

The "-e getLine" trick and the two listed shortcuts fixed my other issues.

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedInvalid

reopened

Sorry, I am using GHC-6.12.3, GHC-7.0.4, GHC-7.2.1 and in all of these versions I cannot delete or move cursor left and right in a line fetched by "getLine" in GHCi. The above comments tell a lot of details, but what is the final fix? Is it intended behaviour that I cannot alter characters I entered to "getLine"?

Trac metadata

Trac field	Value
Version	6.10.1 → 7.2.1
TypeOfFailure	- → OtherFailure
Resolution	ResolvedInvalid → Unresolved

closed

Yes, that is the intended behavior of getLine.

One fix to the problem you've described is to set stdin to LineBuffering, using System.IO.hSetBuffering. On some platforms that will enable the delete key, but probably not the arrow keys.

If you want full interactive behavior for line input, you will need to use a package such as haskeline or readline.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedInvalid

Replying to [ticket:2606#comment:56513 judahj]:

One fix to the problem you've described is to set stdin to LineBuffering, using System.IO.hSetBuffering. On some platforms that will enable the delete key, but probably not the arrow keys.

I tried that on Suse Linux with GHC-6.12.3 and Ubuntu Linux with GHC-7.2.1. It enables delete key but not the arrow keys when I respond to a getLine. But with that mode I cannot see any longer what I enter to the GHCi prompt! I tried hSetEcho stdin True, but this didn't help. :-(

If you want full interactive behavior for line input, you will need to use a package such as haskeline or readline.

How can I find out, whether my GHC was built with haskeline, editline or readline? I use the GHC one from the Linux Tarball.

I believe you're confusing two different things:

The ghci command prompt (e.g., Prelude>). This is used to specify commands which ghci should run. This always (as of ghc-6.10.4, IIRC) uses haskeline and should always enable the use of arrow keys.
The getLine action. This is a specific action which ghci may run as part of a larger function or program. It never uses haskeline, readline, etc.

This ticket was about #1 (closed), not #2 (closed), so most of the above comments don't apply to your issue.

Here's an example of using the haskeline package from within ghci. (Assuming you've already installed it with, for example, cabal install haskeline):

Prelude> :m +System.Console.Haskeline

Prelude System.Console.Haskeline> runInputT defaultSettings (getInputLine "prompt>")

prompt>This is an input line.

Just "This is an input line."

You can look at the documentation on Hackage for more information about the haskeline and readline packages.

With fixed formatting:

Prelude> :m +System.Console.Haskeline
Prelude System.Console.Haskeline> runInputT defaultSettings (getInputLine "prompt>")
prompt>This is an input line.
Just "This is an input line."

added Pnormal label

Backspace, delete, etc. don't work in ghci in HEAD

Child items 0

Activity

Trac field	Value
Version	6.9
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	GHCi
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture	x86