reeflective/readline

Shell library with powerful and modern UI, large feature set, and `.inputrc` support

readline's Issues

expose keymapMode type

Port lmorg/readline code for WASM support

The current original version (located here https://github.com/lmorg/murex/tree/master/utils/readline) includes support for virtual terminals in the browser. Changes are not huge, but require some work and a bit of forethinking here.

Review or enhancements of terminal-specific code

Not being a specialist of raw terminal control, and even less across many platforms,
I'm not really able to enhance of review the reliablity of the following files/directories.

• internal/term/raw_* files
• internal/term/term.go

Comparing with https://github.com/lmorg/murex/utils/readline, most of the code seems to be up to date.
However, reviewing and enhancing those files would probably involve also solving #7.

case insensitive tab completion

offset cursor

was wondering about using this library so i tested it out with my normal prompt and the cursor is slightly offset
the reason for this is because of the delta, since using something like % doesnt make this

it doesn't work on git bash in Windows

What a great library! I'd love to use it in Windows. But I've tried the following combinations and only 1 of them worked:

• git bash - screen goes blank and need to ctrl+c multiple times to exit
• git bash in cmder - same as above
• git bash in Windows terminal - seems the cursor is out of place, and each key stroke prints a newline. see attached.

I'd love to help. I know enough about Go but not enough about terminals. If you can point me in the right direction, I can try to fix it. (If that's even fixable, I know Windows is notoriously bad at terminals...but that's what I am stuck with)
I am mainly interested in fixing it for git bash.

Fix Windows tests for `.inputrc` code

There is a weird bug with Github actions running tests for inputrc package on Windows:
The testdata files are read correctly, but split accordingly to their delimiters.
The tests therefore fail.

Example workflow failure: https://github.com/reeflective/readline/actions/runs/4904982567/jobs/8758471276

Function failing (bytes.Split has everything it needs but does not do its job):

readline/inputrc/inputrc_test.go

Line 181 in 276299f

return bytes.Split(buf, []byte(delimiter))

The tests however work correctly when run locally on a Windows machine.

comments (?) behaviour

Hey! First of all, thank you very much for the work done on this library. I'm enjoying it very much.

I'm opening this issue because I'm unsure if the behaviour I'm observing is intended or a bug and would love some pointers in the right direciton.

I wrote a simple program to explain the issue. It prints to stdout whatever it reads via the readline library in a loop.

👈 Expand to check the code

package main

import (
	"fmt"
	"log"

	"github.com/reeflective/readline"
)

func main() {
	rl := readline.NewShell()

	rl.Prompt.Primary(func() string {
		return " > "
	})

	for {
		line, err := rl.Readline()
		if err != nil {
			log.Fatal(err)
		}

		if len(line) == 0 {
			continue
		}

		if line == "exit" {
			break
		}

		fmt.Println(line)
	}
}

Here's a test run involving the # char:

 > hello
hello
 > "hello"
"hello"
 > #hello
 > "#hello"
"#hello"
 > "#{hello}"
"#{hello}"
 > " #{hello}"
"
 >

In this test run, the last line is both confusing (I didn't expect readline to "eat up" input for me) and causing a nasty bug where I'm using it (the strings I'm feeding to readline may look exactly like the latest here so my code ends up doing the wrong thing).

I tried to look for "comments" in the options of the library but found nothing. The most important question of course is that I'm unsure if this is intended behaviour? (I was slightly surprised to see readline "eating up" the whole '#hello' string too but in a way I understand that better than the latest example).

Extend support for more editors, with some comfort settings

We might extend the edit-command-line functionality with other editors than Vim, and should also probably add an easy way to specify the filetype. Should also, if possible, set the cursor position to the same one in the buffer

Remaining widgets to implement

Other widgets to implement

Commands

• "^[[200~": "bracketed-paste-begin",
• "csi-skip-sequence" (equivalent to ZSH "self-insert-unmeta"),

Options

• enable-bracketed-paste,

Implement proper Windows redisplay on resize

Resize events on Windows are sent through stdin.
The key-reader code in readline currently detects and notifies the display about them, correctly.

Problem

There is a bug that is only triggered when there is no autosuggested line to display for the current input buffer:
On resize event, the cursor is move at the end of the last line of completions, if any, and for no reason (no code in the display engine does such a move), which then causes the redisplay to start at the beginning of the last line of completions.

If there is an autosuggested line displayed at the moment of the resize event, the display handles the refresh just fine.

Attempts

There is commented out code in https://github.com/reeflective/readline/blob/master/internal/display/display_windows.go, which is an attempt at solving this by replacing the cursor back at the current input cursor position, before calling the engine to refresh itself. However this implementation is not stable, it does not work at times,
and it is ugly anyway.

Suspicions

At the first glance, I suspect Windows of introducting a weird behavior on this (which is here to move the cursor after the last non-empty character in the terminal buffer.
Therefore, help from someone with a better instinct and knowledge of Windows terminal internals would be greatly appreciated.

Related files:

• Display engine: https://github.com/reeflective/readline/blob/master/internal/display/engine.go
• Resize events handler: https://github.com/reeflective/readline/blob/master/internal/display/display_windows.go

Don't add empty lines to history

'\' character consumed but not used

Heyo! Thanks for library!

Found an issue while playing around; The \ character appears to be consumed in the background without actually printing/appending to the line editor.

Minimum example:

package main

import (
	"fmt"
	"log"

	"github.com/reeflective/readline"
)

func main() {
	rl := readline.NewShell()

	rl.Prompt.Primary(func() string {
		return " > "
	})

	for {
		line, err := rl.Readline()
		if err != nil {
			if err.Error() == "interrupt" {
				continue
			}
			log.Fatal(err)
		}

		if len(line) == 0 {
			continue
		}

		fmt.Println(line)
	}
}

When I type \, it just goes off into the ether. The final println doesn't contain it either.

Verified that every other key, including it's shifted character (pipe/| on US keyboard) is working as expected.

Let me know if you need any additional info!

consolidating changes/fixes from hilbish's fork

hello. I see that you are back and making fixes to the readline library here. since I incorporated it into hilbish, I have found and fixed a few of the problems I've encountered in it (and added things such as fish-style hints) that I'm sure would be a good fit for upstream. if you want, I can try to update my fork to upstream changes and make a PR.

Implement testing suite

Testing suite

This library currently has no working tests, and if anyone were to implement new features,
it would be great to have a basic, if not thorough, test suite for the library.

Support escape sequences in vi-ins-mode-string & vi-cmd-mode-string

Thanks for this great library! It appears at present escape sequences are not supported for vi-ins-mode-string & vi-cmd-mode-string. I tried setting the following:

set editing-mode vi
# enable mode strings in prompt
set show-mode-in-prompt on
# vi-insert mode use a bar cursor
set vi-ins-mode-string \1\e[6 q\2
# vi-command use a block cursor
set vi-cmd-mode-string \1\e[2 q\2

But the result was the literal escape sequence in my prompt:

example [main] in src/console/example
\e[6>                                                                                               

I found this while trying to use my bash-rsi repo with this library.

Implement multiline editing support

Summary

Currently the shell is able to "preprocess" multiline buffers, and the entire code
for this is inherited from lmorg's original library. Nothing has been changed.

However, the way lmorg handles multiline editing, although definitely working, does
not allow to move around lines of a buffer.

The code is ready for implementing multiline support, it just misses a few things:

• Update selection and yank/paste code to handle multiline in them
  (eg. adding/moving/deleting newlines in selections and buffer).
• Add some logic to line.go for the cursor to be correctly replaced each time.
• Modify the completion engine functions to trim all newlines/tabs in display values.
• Don't remove newlines in the lines each time they are added to history sources.
• Adapt redisplaying the lines when returning from the editor.
• Finish carriageReturnLine() details.
• Need to use a new model for saving history lines (with a timestamp), because now each line is a different history.
• The newline added to each line is counted as a word, solve this.
• Offset is not correct when the line is a virtual completion.
• Cleanup/restructure computeCursorPos() function, possibly remove updateReferences().
• Correctly reinitialize split buffers.
• Handle line wrap for each line in buffer.
• Fix multiline prompt offset when clearing screen
• Fix examples exit prompt, use hint code for message
• Fix offsets when going out of editor with multiline
• Don't move cursor back in cmd mode if at beginning of line.
• Clean up the multiline.go file, probably not needed anymore + fields in instance
• Fix visual highlighting clearing custom highlighting.
• Y and yy have different behaviors: yy acts like visual line.
• Implement correct cursor replacement when deleting a line.
• Log functions should also take into account the multiline buffer lines when offsetting. Something else should do the same ?
• Must check for empty lines in various places: messes the offsets
  [X] Find a way not to account for newlines in cursor movements and words.
• Cleanup edit-command-line widget
• Clearing screen should keep the multiline buffer when entered
• Implement highlighting accounting for secondary cursor.
• Normally the entire buffer should be also passed to completer functions.
• Check if we should actually add a newline between each line returned via rl.lineBuffer() (correct when computing/displaying, but is it useful when returning the line to the caller ? not sure):
  - Should probably replace newlines by spaces: same significance for most shells.