To recreate the error: start Linedit, press Control plus any arrow key. Linedit will appear to freeze and stop accepting input. Press a bunch of keys, and then press ~ or - to escape the freeze. Linedit will return an error (see below), and then it will let you type again.

Unknown command (LINEDIT::UNTRANSLATED
                  (#\Esc #\[ #\1 #\; #\5 #\D #\Esc #\[ #\1 #\; #\5 #\D #\Esc
                   #\[ #\1 #\; #\5 #\D #\  #\a #\f #\a #\d #\f #\s #\d #\f #\s
                   #\a #\f #\g #\[ #\o #\i #\h #\e #\d #\g #\f #\[ #\i #\o #\h
                   #\e #\r #\i #\o #\g #\h #\g #\Esc #\  #\  #\Esc #\[ #\1 #\;
                   #\5 #\D #\Esc #\[ #\1 #\; #\5 #\D #\Esc #\[ #\1 #\; #\5 #\D
                   #\Esc #\[ #\1 #\; #\5 #\D #\Esc #\[ #\1 #\; #\5 #\D #\Esc
                   #\[ #\1 #\; #\5 #\D #\Nul #\s #\d #\g #\; #\l #\k #\s #\d
                   #\j #\h #\f #\g #\l #\; #\l #\k #\d #\s #\j #\r #\g #\f #\[
                   #\o #\w #\e #\i #\j #\g #\r #\5 #\[ #\o #\s #\d #\k #\f #\v
                   #\[ #\o #\e #\r #\i #\8 #\t #\u #\v #\n #\  #\-)).

I tried a lot of keys and key combinations, but only ~ and - seem to break out of the freeze. It took me weeks of randomly trying keys until I discovered this workaround. (I don't know why I didn't try the usual strategy of pressing every single key. That would have been much faster.)

The last typed line is sometimes clobbered after activating this bug (i.e. sometimes cleared, sometimes the beginning is missing), so that might be another bug.

I would happily do the work to fix this bug, but I'm not sure what to do. Do I simply need to add four Linedit commands (i.e. one for each arrow)? Or is there more work necessary?

If for some strange reason this can't get fixed, at least that one poor soul stuck at a frozen terminal might find relief after reading this.

Invoking e.g. (linedit:install-repl :wrap-current t :eof-quits t) on SBCL causes the following error:

#<THREAD "main thread" RUNNING {10005505B3}>:
  Invalid file format

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(TERMINFO::LOAD-TERMINFO "xterm-256color")
   source: (ERROR "Invalid file format")

The same call has comparable results on CCL. I'm using Arch Linux 4.17.3-1 x86_64, SBCL 1.4.8, CCL 1.12-dev. TERM is set to xterm-256color. Thanks in advance.

I am using linedit for years on different machines with different versions of SBCL without issues but on my latest installation it fails during start-up of SBCL with the following error:

Linedit version 0.17.6, smart mode, ESC-h for help.

debugger invoked on a OSICAT-POSIX:EFAULT in thread
#<THREAD "main thread" RUNNING {7005320673}>:
  #<EFAULT OSICAT-POSIX::%IOCTL-WITH-ARG 14 :EFAULT "Bad address">

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

((FLET "CLEANUP-FUN-14" :IN LINEDIT:LINEDIT)) [cleanup]
   source: (WITH-BACKEND *EDITOR* (EDIT))
0]

It loads via quicklisp without problems, but fails as soon as I install the REPL with (funcall (intern "INSTALL-REPL" :linedit) :wrap-current t).

Any ideas what's wrong here and what I can do to solve this issue?

Thanks
Martin

Behavior

(progn (load "/home/lerax/.emacs.d/elpa/slime-20190210.1101/swank-loader.lisp" :verbose t) (funcall (read-from-string "swank-loader:init") :from-emacs t) (funcall (read-from-string "swank:start-server") "/tmp/slime.2766"))

Linedit version 0.17.6, dumb mode, ESC-h for help.

debugger invoked on a SIMPLE-ERROR in thread #<THREAD "main thread" RUNNING {10005205B3}>: BUG: You seem to have found a bug in Linedit.
Please report this incident along with directions to reproduce to
    https://github.com/sharplispers/linedit

'Invariant (LINEDIT::BACKEND-READY-P LINEDIT::BACKEND) violated.'

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

((:METHOD LINEDIT::BACKEND-CLOSE (LINEDIT::TERMINAL)) #<LINEDIT::DUMB-EDITOR {100269BB03}>) [fast-method]
   source: (INVARIANT (BACKEND-READY-P BACKEND))

Slime side ^
At .sbclrc: http://ix.io/1CgK/lisp

Expected

Works calling sbcl from terminal and from slime.

Hello,

I am working on moving to sbcl as my main REPL on my UNIX systems and wanting to keep tab completion, I decided to install this package, but there is one major issue. In my CL REPL configuration, I define many functions that essentially operate like UNIX shell aliases, but whenever I call them no output is ever shown. To fix this problem, I have to kill linedit and only use the sbcl prompt. Is this an issue on my end or a problem with linedit?

It seems that with all of the latest advances in terminal support for Windows (e.g. ConPTY), that linedit should be able to run on that platform, and I see that @dparnell has started the process in his fork. This possibly could become a osicat issue, but given the specific nature of the problem, TTY support, seems like it best handled within linedit, either directly or via one of the available tty libraries.

Does anyone know if linedit works under WSL 2?

I'm looking at using linedit for one of my projects (https://github.com/bradleyjensen/shcl). I have, shall we say, unusual requirements. I do weird things with *standard-input*, for example. Your README says that the consequences are unspecified if *standard-input* has been modified.

Can I get a slightly stronger guarantee than "literally anything can happen if you rebind *standard-input*"?

As i tried,
(linedit:install-repl :wrap-current t :eof-quits t) doesn't work on prepl, either install-repl first, or (prepl:repl) first. It would be nice to have them work together