reeflective / readline Goto Github PK
View Code? Open in Web Editor NEWShell library with powerful and modern UI, large feature set, and `.inputrc` support
License: Apache License 2.0
Shell library with powerful and modern UI, large feature set, and `.inputrc` support
License: Apache License 2.0
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!
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
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_*
filesinternal/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.
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.
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
The tests however work correctly when run locally on a Windows machine.
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.
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:
selection
and yank/paste
code to handle multiline in themline.go
for the cursor to be correctly replaced each time.carriageReturnLine()
details.computeCursorPos()
function, possibly remove updateReferences()
.multiline.go
file, probably not needed anymore + fields in instanceY
and yy
have different behaviors: yy
acts like visual line.rl.lineBuffer()
(correct when computing/displaying, but is it useful when returning the line to the caller ? not sure):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.
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:
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.
Resize events on Windows are sent through stdin.
The key-reader code in readline
currently detects and notifies the display about them, correctly.
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.
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.
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:
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.
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).
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.