kkawakam / rustyline Goto Github PK

Entries with whitespace at the beginning of the string are excluded from the history object by history.rs:34. Perhaps the line could be replaced with if line.trim().is_empty() { so that only lines entirely made of whitespace are excluded?

Add custom rustyline error that implements std:Error trait and the std::convert::Error trait

Reference

Disable echo...

Completing paths which include spaces does not work currently, as the space is part of the DEFAULT_BREAK_CHARS array and so extract_word does not extract the whole path.

A workaround is to remove it from the list and making sure that you only pass the path without any prefix to the FilenameCompleter.

A proper fix would probably be doing what windows does: Adding quotes around the path if it contains a space.

We could do:

for cmd in editor {
    match ...
}

It would end on EOF or

Could you push another release to crates.io? On the latest Rust nightly, 0.2.0 fails to build, but the latest revision seems to compile fine.

Thanks a bunch!

Currently we take advantage of some non-stabilized rust APIs but eventually we will want to be able to compile against Rust stable. The below links are tracking issues that need to be closed out before we can compile against rust stable.

Update June 6 2016: #38 introduced workaround changes that allowed rustyline to be compiled against rust stable (1.9.0). These changes should eventually replaced by Read::chars and encode_utf8 after they become stabilized in the standard library.

TO-DO

• Read::chars
  • rust-lang/rust Tracking Issue
  • replace workaround introduced in #38 (remove char_iter.rs)
• encode_utf8
  • rust-lang/rust Tracking Issue
  • replace workaround introduced in #38 (remove encode_unicode crate)
• str_char
  • rust-lang/rust Tracking Issue
  • stabilized in Rust-1.9
• path_relative_from
  • rust-lang/rust Tracking Issue
  • stabilized in Rust 1.7
  • change from path_relative_from to strip_prefix was addressed in #23
• vec::Drain
  • rust-lang/rust Tracking Issue
  • stabilized in Rust 1.6

Great library thanks. You may want to update the README.md to 0.2.0:

[dependencies]
rustyline = "0.2.0"

See https://github.com/danburkert/ksql/blob/master/src/main.rs#L199

Hi everyone,

I just built an example project with rustyline 1.0.0 and code as in the documentation:

extern crate rustyline;

fn main() {
    let mut rl = rustyline::Editor::<()>::new();

    let readline = rl.readline(">> ");

    match readline {
        Ok(line) => println!("Line: {:?}",line),
        Err(_)   => println!("No input"),
    }
}

I am running this example in a unicode-rxvt terminal ($TERM=rxvt), and the usual keybindings M-b, C-a and even Enter only generate their literal codes:

% cargo run
    Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/readline`
>> españa^[b^A^M
>> españa
Line: "españa"

I can submit the line with C-j though.

I am running rxvt-unicode-9.22 and rust-1.13.0.

Any help will be greatly appreciated. Thanks!

If I load_history() from a PathBuf that does not point to an existing file - what happens?

The information is missing in the documentation.

Last one was in August, there are some neat unreleased features!

Error: Io(Error { repr: Os { code: 6, message: "The handle is invalid." } })

For example, running the below code results in SUCCESS never being printed.

extern crate rustyline;

use rustyline::Editor;
use rustyline::error;

fn main() {
    let mut editor = Editor::<()>::new();
    loop {
        match editor.readline("1\n>> ") {
            Ok(_) => println!("SUCCESS"),
            Err(error::ReadlineError::Eof) => break,
            Err(_) => continue,
        }
    }
}

actual:

1
>> foo
1
>>

expected:

1
>> foo
SUCCESS
1
>>

• readline method should return custom error type that will be created when #1 is fixed
• compose error handling into a easily readable format

Reference

I'm attempting to create a multi-line prompt by using a newline character in the argument to Editor::readline, e.g. readline("foo\n> ")

I expected this to produce

foo
>

but it is instead producing

foo
   >

Is this a problem with rustyline, or am I doing something incorrectly?

I was messing with rustyline, it's completion API and trying do implement multiline editing at the same time, but then I encountered a problem: I need to have the input from the previous lines to have a proper context for my completion system.

Sorry if it's unclear, here's a quick example:

input> if [ x -eq 1 ];
  ...> th<tab>

In this case, my completer need to know that there's an if before to be able to complete the then.

My idea was to store the previous lines as context inside the Completer, but currently there is no way of retrieving the completer in use.

A see two ways of doing this: either make the completer field public or add the get_completer and get_completer_mut methods.

For now, I can do it by replacing the current completer with the added context, but I think that would be better by mutating the completer directly.

If there's a better way, please tell me, I'm open to discussion ;-)

To handle file completion like this ls ~userX/.

users = "0.5.1"

if let Some(user) = users::get_user_by_name("userX") {
    let home_dir = user.home_dir();
    // ...
}

GNU readline support bind a keypress via INPUTRC like this:

bind '"\e[A":history-search-backward'
bind '"\e[B":history-search-forward'

It would be great if rustyline support this.

Another option (for this specific function), rustyline can let users to customize the some KeyPress event, like this one, and provides low level APIs to manipulate prompted commands via history entries etc.

Thanks for this awesome project!

If possible, avoid a full refresh of the line but move only the cursor when user press Ctrl-A, Ctrl-E, ...

https://www.reddit.com/r/rust/comments/4jufvh/which_readlinelike_crate/d3afuv8

I really wish there was a readline-like library which worked for windows as well.

I like this great project, but it seemed IME is not supported for now (at least in Windows).

Missing code comments and documentation :(...

Reference

There seems to be something wrong:

$ git clone https://github.com/kkawakam/rustyline
Cloning into 'kkawakam-rustyline'...
remote: Counting objects: 125450, done.
remote: Total 125450 (delta 0), reused 0 (delta 0), pack-reused 125450
Receiving objects: 100% (125450/125450), 39.23 MiB | 4.30 MiB/s, done.
Resolving deltas: 100% (120354/120354), done.
$ cd rustyline
$ du -h -d 1
 43M	./.git
4.0K	./examples
144K	./src
 43M	.

It seems that some html/javascript files haven been added/commited.
Using the script described here

All sizes are in kB. The pack column is the size of the object, compressed, inside the pack file.
-e    size  pack                                      SHA                                              location
1158  102   ac022cdad0792d6b5a92443591a4a13447dd2f61  src/libc/lib.rs.html
889   156   18fb8e7d017939a7866d770f2f128dcf06f982cb  search-index.js
561   25    05cc9269d38aa0db6623f9f10e622ec3afad2870  nix/sys/ioctl/libc/index.html
364   57    67285d0679fe8741691acfff97c6223f7baadd64  search-index.js
337   10    35865ffd48354a252b1b9623af51e7b912934f4a  bitflags/__core/prelude/v1/trait.PartialEq.html
268   25    10323005747653adee46df009b7abf73c9d728ef  bitflags/__core/prelude/v1/struct.Vec.html
261   13    94a89fd9eac872d1468b183ad64168d6df682e7e  nix/sys/ioctl/libc/index.html
250   21    03df2507089f9edf622152bab56a4355d54d143d  bitflags/__core/prelude/v1/trait.Iterator.html
235   29    e44dca71087bbbaeca108a13aa1160a1fd80baf2  bitflags/__core/prelude/v1/struct.String.html
233   25    3216db156c7d32d82655051fce4b1039c79a029e  src/nix/errno.rs.html

Would you mind trying to cleanup this stuff ?
Thanks.

I saw that windows support is (partially) available for rustyline now so I was considering removing my linenoise-rust dependency and use this instead as the completion support was to primitive for my needs.

Looking at the API however I am going to run into problems with Completer being a borrowed trait object as the current implementation mandates a borrow and prevents Editor from being Sync. This could be solved by instead parameterising Editor by the Completer.

I'd be happy to implement this and submit a PR if you think it is a good idea.

See https://github.com/unicode-rs/unicode-segmentation (and https://github.com/DanielKeep/strcursor).

cargo build --target=x86_64-unknown-linux-musl fails with:

$ cargo build --target=x86_64-unknown-linux-musl
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling rustyline v0.2.3 (file:///home/bjb/code/rustyline)
src/lib.rs:247:48: 247:58 error: mismatched types [E0308]
src/lib.rs:247         match libc::ioctl(libc::STDOUT_FILENO, TIOCGWINSZ, &mut size) {
                                                              ^~~~~~~~~~
src/lib.rs:247:48: 247:58 help: run `rustc --explain E0308` to see a detailed explanation
src/lib.rs:247:48: 247:58 note: expected type `i32`
src/lib.rs:247:48: 247:58 note:    found type `u64`
error: aborting due to previous error
error: Could not compile `rustyline`.

I have a simple fix, will do a pull request shortly.

I would like rustyline to blink the matching delimiter once I type it. Is there any reason you see why this shouldn't work in the library? Otherwise, I can put together a pull request.

I would think to start with () but I don't see an immediate reason to not add {} []. Perhaps it should be configurable for the user?

The library calls refresh in the cursor movement functions causing future lines to be wiped out. This is causing issues for a game I embedded the line editor in, because the bottom portion of the screen gets wiped if the user moves the cursor while entering a command.

https://github.com/BurntSushi/tabwriter may be useful.

Currently there are no test cases for rustyline.

As an initial test case, a UTF-8 string should be written to STDIN file descriptor and see if the correct string is returned by rustyline.

thread 'main' panicked at 'attempted to multiply with overflow', src\lib.rs:255

https://github.com/DanielKeep/rust-ansi-interpreter

Have you consider implement vi mode ?

however great project thanks.

Since rustyline removes the ISIG flag from the terminal, pressing Ctrl-Z or Ctrl-\ will insert a character instead of suspending/quitting the process. Especially suspend is quite essential for any CLI program.

Please consider using the default signal handling, or implementing some kind of handler for Ctrl-Z and Ctrl-\ that generates the signals.

http://cnswww.cns.cwru.edu/php/chet/readline/rluserman.html#SEC21

undo (C-_ or C-x C-u)
Incremental undo, separately remembered for each line.

revert-line (M-r)
Undo all changes made to this line. This is like executing the undo command enough times to get back to the beginning.

https://github.com/antirez/linenoise#hints

It is hard to know on which platform/terminal the problem appears but:
rustyline, which had some functionality problems (home/end keys didn't work, among other things).

Or a Into<String>

encode_unicode 0.1.3 -> 0.3.0
nix 0.5.0 -> 0.8.1

The README mentions multiline support, but I can't find a way to enable it. Is this feature implemented?

Editor::readline returns a Result<String>. Would it not make more sense for this to return a Result<OsString>?

Going to yank 0.2.2 after a fix is in place.

The writeln() in escape_sequence should probably be removed in released versions.

Thanks for your work on rustyline btw! Apart from the other issue I raised it works beautifully for me as a simple REPL line editor.

Like in gdb. Imagine you enter step. If after that you press enter with an empty command line, it will repeat step. It's really handy for debuggers for example. It would not be used in all cli interfaces, though.

At least on Unix.
http://stackoverflow.com/questions/33646418/how-to-read-an-utf-8-char-from-a-terminal-with-a-timeout

Error: Decode(DecodeUtf16Error { code: 55378 })

55378 is D852
https://en.wikipedia.org/wiki/UTF-16
https://play.rust-lang.org/?gist=a94c3ab045a1debe20fee6cfb4430c3a&version=nightly&backtrace=0