This makes sure that if we are editing in multi-line mode a line that
actually spawns across multiple lines, the next output performed by the
application using linenoise will not overwrite the edited line.
OSX default Terminal app does not handle 999D well, the cursor will wrap
back to the previous row in the last colum, instead of ignoring the
sequence if the cursor is already at the left edge.
In order to avoid reintroducing the nG sequence that is not compatible
with base VT100 emulation and ANSI.SYS, we use CR that should be
hopefully widely supported.
This fixes a bug introduced with ANSI.SYS compatibility.
When we want to move at a specific column, we need to emit the sequence
to move the cursor to the right (after we moved 999 positions to the left)
only if we want to actually move right at least 1 position, since a
count of zero will still move the cursor one position to the right.
Github user @welash proposed a change in issue #73 in order to improve
the linenoise compatibility with older terminal emulators only able to
deal with a subset of ANSI sequences, notably ANSI.SYS and VT100
terminals strictly able to handle the original set of VT100 escape
sequences.
In order to improve the compatibility, the CHA sequence was removed and
translated to move 999 positions to the left, then move on the right
for the desired number of positions. The CHA sequence was apparently
added only with VT220, that's why it is not available everywhere.
This commit features almost exactly the change proposed in issue #73
with a small fix for a bug in multi-line editing mode introduced by the
patch.
Some terminal reports ESC [H and ESC [F, while some other reports
ESC OH and ESC OF. We support both but there is at least another
variant documented, hopefully no longer.
This change makes linenoise both more robust if the ioctl() fails, and
far more portable to non POSIX systems, since the ioclt() to query the
terminal was probably one of the non trivial parts to replace.
The code is inspired to Andreas Kupries commit 24186e99 on the win32
Linenoise port from Steve Bennett, but is a complete reimplementation.
Many sequences are actually human readable and fall into the printable
ASCII subset, they are a lot more recognizable when written as chars
compared to numbers.
For example up arrow is sent back from the terimal as ESC [A, and so
forth.
This commit makes the code speak the same "language" that you find in
any terminal escape sequences documentation.
What we print in debug mode using the option (now) called --keycodes
are not the scan codes, but the key codes returned by the terminal (a
more higher level representation of the keys pressed).
This commit fixes the word used.
The read call in the escape sequence processing does not
handle the case where only the first byte is available. This can
happen for example on a slow serial terminal.
Comment by @antirez:
I reworked the code for brevity, for historical reasons here is the
proposed patch. I believe my fix should be functionally equivalent.
Original fix:
case 27: /* escape sequence */
/* Read the next two bytes representing the
escape sequence. */
- if (read(fd,seq,2) == -1) break;
+ {
+ ssize_t b = read(fd, seq, 2);
+
+ if (b < 0) break;
+
+ if (b == 1) {
+ b = read(fd,&seq[1], 1);
+ if (b != 1) {
+ break;
+ }
+ }
+ }
See PR #47.
Escape sequences and actual content to write to the terminal is now
accumulated into an heap allocated buffer that is flushed with a single
write at the end. This avoids a flickering effect making linenoise more
professional looking ;-)
The Emacs terminal emulator has its own line editing and does not
behave correctly in raw mode. Without this programs using linenoise
will hang when run inside an Emacs shell.
