xi-frontend / xi-term Goto Github PK

Hi,

Here is what happens when I try to open a file with ~65k (around 0xffff) or more symbols:

(bash) # for f in {0..781}; do echo "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX line $f" >> test.dat; done
(bash) # xi-term ~/test.dat 2>error.log
(bash) # # xi-term opens and immediately crashes
(bash) # cat error.log

thread 'tokio-runtime-worker-3' panicked at 'attempt to add with overflow', src/widgets/view/view.rs:324:21
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
thread 'tokio-runtime-worker-2' panicked at 'called `Result::unwrap()` on an `Err` value: SendError("...")', src/libcore/result.rs:997:5

I traced the output logs of xrl and found that xrl is receiving the full contents of test.dat from xi-core, concatenated into a single very long line with "\n"'s (which is definitely unexpected; this huge line is added to linecache without any splitting):

2019-09-25T01:44:12.393891388+03:00 DEBUG xrl::protocol::endpoint - handling message from remote peer Notification(Notification { method: "update", params: Object({"update": Object({"annotations": Array([Object({"n": Number(1), "payloads": Null, "ranges": Array([Array([Number(0), Number(0), Number(0), Number(0)])]), "type": String("selection")})]), "ops": Array([Object({"lines": Array([Object({"cursor": Array([Number(0)]), "ln": Number(1), "styles": Array([]), "text": String("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX line 0\nXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX line 1\nXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX line 2\n <...SNIP...>XXXXXXXXX line 781\n")})]), "n": Number(1), "op": String("ins")}), Object({"n": Number(771), "op": String("invalidate")})]), "pristine": Bool(true)}), "view_id": String("view-id-2")}) })

No surprise that view.rs encounters an u16 overflow here.

Disclaimer: I still don't know whether this is the problem of xi-term, xrl, or xi-core.

Thanks

#69 is merged we have the ability to run commands from the TUI. So we'll need to start discussing what commands should be implemented, what a command sould look like anyway.

In #69 for Command structure i chose to have 2 forms of each command a 'long' and 'short' version, so for example to save the current buffer you could type 's' or 'save' and they are seen as the same command. But is this really the best way to go?

Here is a list of possible commands that xi-core already does for us(but we dont implement) and what i think there key bindings should be:

• quit ('q', 'quit')
• save ('s', 'save')
• close ('c', 'close')
• backspace ('b', 'back')
• delete ('d', 'delete')
• open file ('o', 'open')
• next buffer ('bn', 'next-buffer')
• prev buffer ('bp', 'prev-buffer')
• search ('?', 'search')
• page down ('pd', 'page-down')
• page up ('pu', 'page-up')
• move left ('ml', 'move-left')
• move right ('mr', 'move-right')
• move up ('mu', 'move-up')
• move down ('md', 'move-down')
• left select ('sl', 'select-left')
• right select ('sr', 'select-right')
• up select ('su', 'select-up')
• down select ('sd', 'select-down')
• display themes? ('ts', 'themes')
• set theme ('t', 'theme')

Currently, you can run ^c and exit with unsaved work, and xi-term will exit without warning.

Ideally, the "normal" exit should not work with unsaved text. I think vim handles this nicely, where one usually exits with :q, but this does not work with unsaved work. Instead, vim warns you of this but also lets you use :q! instead.

Details

-Linux 5.15.0-53-generic #59~20.04.1-Ubuntu SMP Thu Oct 20 15:10:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

• rustc 1.65.0 (897e37553 2022-11-02)
• installed from source

thread 'tokio-runtime-worker-0' panicked at 'attempted to leave type internal::Local uninitialized, which is invalid', /home/lm/.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam-epoch-0.7.1/src/internal.rs:493:59 stack backtrace: 0: 0x55b7468c88f0 - std::backtrace_rs::backtrace::libunwind::trace::h32eb3e08e874dd27 at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5 1: 0x55b7468c88f0 - std::backtrace_rs::backtrace::trace_unsynchronized::haa3f451d27bc11a5 at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5 2: 0x55b7468c88f0 - std::sys_common::backtrace::_print_fmt::h5b94a01bb4289bb5 at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys_common/backtrace.rs:66:5 3: 0x55b7468c88f0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hb070b7fa7e3175df at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys_common/backtrace.rs:45:22 4: 0x55b7468ed7fe - core::fmt::write::hd5207aebbb9a86e9 at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/fmt/mod.rs:1202:17 5: 0x55b7468c5975 - std::io::Write::write_fmt::h3bd699bbd129ab8a at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/io/mod.rs:1679:15 6: 0x55b7468ca2c3 - std::sys_common::backtrace::_print::h7a21be552fdf58da at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys_common/backtrace.rs:48:5 7: 0x55b7468ca2c3 - std::sys_common::backtrace::print::ha85c41fe4dd80b13 at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys_common/backtrace.rs:35:9 8: 0x55b7468ca2c3 - std::panicking::default_hook::{{closure}}::h04cca40023d0eeca at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:295:22 9: 0x55b7468c9faf - std::panicking::default_hook::haa3ca8c310ed5402 at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:314:9 10: 0x55b7468ca96a - std::panicking::rust_panic_with_hook::h7b190ce1a948faac at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:698:17 11: 0x55b7468ca821 - std::panicking::begin_panic_handler::{{closure}}::hbafbfdc3e1b97f68 at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:586:13 12: 0x55b7468c8d9c - std::sys_common::backtrace::__rust_end_short_backtrace::hda93e5fef243b4c0 at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys_common/backtrace.rs:138:18 13: 0x55b7468ca582 - rust_begin_unwind at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:584:5 14: 0x55b74676a6f3 - core::panicking::panic_fmt::h8d17ca1073d9a733 at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:142:14 15: 0x55b74676a5bd - core::panicking::panic::hf0565452d0d0936c at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:48:5 16: 0x55b74682483a - <crossbeam_epoch::internal::Local as crossbeam_epoch::sync::list::IsElement<crossbeam_epoch::internal::Local>>::entry_of::h2d33d5788ee0257b 17: 0x55b746824c24 - crossbeam_epoch::collector::Collector::register::hbc53afbaae10ffb3 18: 0x55b74681e2bd - std::thread::local::lazy::LazyKeyInner<T>::initialize::h3bb7a88b522f6243 19: 0x55b74681e694 - crossbeam_deque::Stealer<T>::steal_batch_and_pop::hf3b1f347d058cea2 20: 0x55b746812e33 - tokio_threadpool::worker::Worker::run::h94b6a411945fb145 21: 0x55b74680652b - tokio_trace_core::dispatcher::with_default::h1cf17342ee37eeb7 22: 0x55b7467ff74f - std::thread::local::LocalKey<T>::with::h63be62a179d5a083 23: 0x55b7467ff8f3 - std::thread::local::LocalKey<T>::with::hadcee93c82a6a398 24: 0x55b746800f97 - tokio::runtime::threadpool::builder::Builder::build::{{closure}}::h504195ce6181288b 25: 0x55b746815d8c - std::thread::local::LocalKey<T>::with::haeaad6fe5d807462 26: 0x55b746815ea8 - std::thread::local::LocalKey<T>::with::hdbdb231a93bacdab 27: 0x55b74681d397 - std::sys_common::backtrace::__rust_begin_short_backtrace::h3c553417cecc0568 28: 0x55b74681c5be - core::ops::function::FnOnce::call_once{{vtable.shim}}::hc777b5ca596c2879 29: 0x55b7468cf033 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h49f797984e2121bf at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/alloc/src/boxed.rs:1940:9 30: 0x55b7468cf033 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hfa4f3d0ee6440e0b at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/alloc/src/boxed.rs:1940:9 31: 0x55b7468cf033 - std::sys::unix::thread::Thread::new::thread_start::h62ca48b42d48a8fc at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys/unix/thread.rs:108:17 32: 0x7f2d2292a609 - start_thread at /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c:477:8 33: 0x7f2d226fa133 - clone at /build/glibc-SzIz7B/glibc-2.31/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95 34: 0x0 - <unknown>

Right now every invalid line is explicitly stored in the cache which means every update will copy a lot of invalid lines for large files. Most other front-ends have two integers that store the number of invalid lines before and after the lines that are explicitly stored. Take a look at the implementation in xi-mac, xi-gtk and gxi. If you want to I can also explain the concept in more detail.

Hello,

I'm very pleased to announce that xi-term is now included in FreeBSD ports:

https://www.freshports.org/editors/xi-term/

Future plans:

• Port syntect so we can have syntax highlight
• A manual writen in mdoc format. I will fork this project, create a manual and then see if it is accepted.

Thanks,

Nuno Teixeira

I tried running xi-tui on a README.md file and it crashed like this:

$ RUST_BACKTRACE=1 xi-tui README.md 
thread 'main' panicked at 'failed to spawn xi-core: Error { repr: Os { code: 126, message: "Required key not available" } }', /checkout/src/libcore/result.rs:906:4
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:69
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:58
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::result::unwrap_failed
  10: xi_tui::run
  11: xi_tui::main
  12: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:99
  13: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:459
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:59
  14: __libc_start_main
  15: _start

Given #5, #9 and the changes I've been working through for #7, I think it may be prudent to find the last stable version of the core this frontend worked with, and advertise that in the README, until we can properly overhaul the frontend to work with the latest protocols

I love termion, but it doesn't work on windows witch is frustrating cause i have to use windows at work but would like to hack on the same projects i do at home on my Linux. Termion does have an issue about windows support 103 witch i've commented on asking the status of, but it seems to have gone stale

To clarify by cross platform i only mean Linux/Windows, those are the only operating systems i can test on (as well as the only one's i ever use). I'm not against supporting apple/macos i'm just not able implement it.

If we decide to move away from termion for windows support one possiblity would be crossterm it seem's similar enough to termion to make

xi-term need's to be refactored in order to continue adding components, Id like to change the directory structure to make this easier. I don't plan on changing any code with this change just organize the modules and files.

I think there the best way to do this(for now at least) is to create two sub-modules, 'core' & 'widgets'.

The core module will hold files like tui.rs and terminal.rs as well as provide a place to add 'TUI' code and other core functionalities.

The widgets module will hold all the on screen display items. eg. Editor Views, Status bar, and Command prompt, as well as any future widgets we decide to implement.

So TLDR; I'd like this to be the project structure at least for the time being:

xi-term/
   ├──core
          ├──tui.rs
          ├──terminal.rs
          └──mod.rs
   ├──widgets
           |──view
           |    └────same as current
           └──mod.rs
   ├──main.rs

@little-dude I don't have the appropriate permissions, but I'd love to start writing some unit tests for various parts of the frontend, and configure travis to block PRs for broken builds. Can you take care of that (or give me superpowers)?

xi-tui will first open log_config.yaml when opening:

https://github.com/little-dude/xi-tui/blob/master/src/main.rs#L62

If there is no log_config.yaml, unwrap will fail.

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Log4rs(Error { repr: Os { code: 2, message: "No such file or directory" } })', /checkout/src/libcore/result.rs:906:4
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:23
  10: <core::result::Result<T, E>>::unwrap
             at /checkout/src/libcore/result.rs:772
  11: xi_tui::run
             at src/main.rs:62
  12: xi_tui::main
             at src/main.rs:44
  13: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:99
  14: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:459
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:59
  15: main
  16: __libc_start_main
             at ../csu/libc-start.c:308
  17: _start

Hello,

It is possible to have syntect-plugin as a feature in Cargo.toml like, e.g.:

[features]
default = ["dist-client", "s3"]
all = ["dist-client", "redis", "s3", "memcached", "gcs", "azure"]
azure = ["chrono", "hyper", "hyperx", "rust-crypto", "url"]

(example from sccache Cargo.toml project)

I'm asking this because I'm porting xi-term to FreeBSD and it will be more easy to me to use:
.
CARGO_FEATURES= syntect-plugin
or
CARGO_FEATURES= all
if there are more features that we like to have activated in a port.

I have not ported your project yet but I am using/testing it and it works very well.

Thanks,

Nuno Teixeira

Hi, followed the instructions but keep getting this error:

    Finished release [optimized] target(s) in 0.07s                             
     Running `target/release/xi-term dummy`
thread 'main' panicked at 'failed to spawn xi-core: Os { code: 2, kind: NotFound, message: "No such file or directory" }', libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Any suggestions or a manual?
Thanks

EDIT:

stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:477
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:391
   6: rust_begin_unwind
             at libstd/panicking.rs:326
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::result::unwrap_failed
   9: xrl::core::spawn
  10: xi_term::main
  11: std::rt::lang_start::{{closure}}
  12: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  13: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:103
  14: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  15: main
  16: __libc_start_main
  17: _start

As discussed in #19, removing the "ignore dead code" directive for core.rs makes the output of cargo build quite noisy.

We should clean up this code before we remove the directive, to prevent build logs from being too noisy to be helpful.

I have installed xi-core and xi-term in /usr/bin, and syntect in /usr/share/xi/plugins/.

When I open file in xi-term I didn't get syntax highlight.

xi-term.log

xi-term.rpc.log

xi-core.log

Incorrect positioning of the cursor while typing, after I press tab.

I just typed s" but the cursor is highlighting a. This error ocured after I pressed tab to indent.

It's nice to have line numbers, but not always. I think we should have a command to toggle that like emacs does as linum-mode. Maybe M-x ln ? ln: line numbers.

This doesn't appear to work with recent builds of xi-editor. In particular, the syntax for updates has changed significantly. See the following for more information:

https://github.com/google/xi-editor/blob/protocol_doc/doc/update.md

Afaik Xi has support of multicursors, does xi-term support it?

I got this when trying to run:

xi-term (master)$ cargo run --release -- <file>
error: current package believes it's in a workspace when it's not:
current:   /home/roman/personal_projects/rust/vendor/xi-editor/rust/xi-term/Cargo.toml
workspace: /home/roman/personal_projects/rust/vendor/xi-editor/rust/Cargo.toml

this may be fixable by adding `xi-term` to the `workspace.members` array of the manifest located at: /home/roman/personal_projects/rust/vendor/xi-editor/rust/Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.

I have this:

$ cat ~/.config/xi/preferences.xiconfig 
theme = "InspiredGitHub"

Setting theme manualy works:

:t InspiredGitHub

logfile.txt

logfile.rpc.txt

Docs are here

C-c will put the terminal in a messed up state that requires running reset (or some equivalent command). It seems that SIGINT isn't being caught in order to exit curses mode and restore tty mode.

We currently completely disregard the styles vector in Lines that we receive from the backend. We should maybe (?) do something with this

Currently all xi-term layout happens within the Tui struct, as we add more component's this will get unwieldy.

My idea is to create a Widget trait and a InputResult enum. Inside the Tui struct there will hold a vector of widgets as well as the index of the active widget. as Tui reads input events it will pass them along the the active widget and re-render if required

pub trait Widget {

    fn handle_input(&mut self, event: Event) -> InputResult;

    // `TerminalWriter` is just a placeholder name.
    fn render(&self, w: TerminalWriter) -> io::Result<()>;
}

pub enum InputResult {

    // Keep Current widget active, and redraw.
    Continue,

   // Keep current widget active, but no redraw
    None,

   // Remove the currently active widget
    Close,
}

Widget

A Widget is simply an object that can handle input events and draw itself to a terminal.
Currently most of the render functions take W: Write as an argument this would have to be changed to a typed value(Since we ultimatly want a Vec and traits with generic members can't be turned into trait objects), this mean's we'll loose being able to render to any std::io::Write.

InputResult

The InputResult enum is how a widget pass's actions to the tui, for the current view widget this would always be the 'Continue' (or 'Close' if ^q is pressed). When a Command Prompt is implemented this would also be updated with a Command(EditorCommand) variant.

With these to abstractions we could cleanup the Tui struct and get it ready for adding, other components without cluttering things up too much.

Vim is the only editor I know so I'm very tempted to mimic its behaviour.

For now it is blocked because there is currently no way in termion to detect a single Esc press, but it should be possible after this PR gets merged.

Related discussions:

• xi-editor/xi-editor#93
• xi-editor/xi-editor#85
• xi-editor/xi-editor#14
• xi-editor/xi-editor#12

It looks like this:

scroll_to [line, col]

I'm not sure the best way to handle this, since we lose the height and first_line information that we get with other update requests. This may mean that we need to maintain a local copy of the current "lines" buffer to handle the scrolling, but I'm not sure at this point.

Perhaps using something like this... https://github.com/rschmitt/heatseeker/blob/master/src/screen/windows.rs

Just as the title says, the backspace does not work in xi-term when launched in UXTerm (urxvt, rxvt-unicode) on GNU/Linux (Arch Linux).
From urxvt-help:

urxvt --help
rxvt-unicode (urxvt) v9.22 - released: 2016-01-23
options: perl,xft,styles,combining,blink,iso14755,unicode3,encodings=eu+vn+jp+jp-ext+kr+zh+zh-ext,fade,transparent,tint,XIM,frills,selectionscrolling,wheel,slipwheel,cursorBlink,pointerBlank,scrollbars=plain+rxvt+NeXT+xterm

xi-term launched with cargo run --release -- ~/test/test.cpp
Both xi-core and syntect-plugin are installed and running.

I also tested xi-term in Gnome Terminal, and it ran without any issue, hence I suspect UXTerm to be the cause of this issue.

Currently we're using error-chain but it seems that failure is going to be new standard for error handling.

Would it be possible* to post the current key-bindings or link to them in the README if they exist elsewhere?
*Fixed a typo

how do i save ? i saw this:
For now, there are only two shortcuts:
^w saves the current view
^c exits

but where do i type these commands, it just writes the commands it in the file i'm editing

sorry i just couldn't figure it out :/

We should start thinking about what a version 0.1.0 would look like, so i/we can begin working towards that goal. I think we should list all the desired features/bug fixes for a 0.1.0 version in this issue.

I'll start:

1. A Way to view error messages.

 Currently there is no way for xi-term to communicate something to the user through the UI only through the optional log file. there should be a little widget (I think on the bottom near on top of the command prompt) that can display a message.

2. Horizontal Scrolling

 Currently xi-term ignores everything to the 'right' of the window, we need to track the horizontal position of the cursor to display the correct section of the line cache.

3. Find

  Implement a Find command i think for the first version this should just be simple.

4. Optimize cursor rendering

 The cursor still flashes when changing cursor position rapidly. Hold the 'down arrow' key with a large file open and you'll se what i mean. 'This is mostly just annoying and should be fixed before we start versioning.

Are there any other features anyone would like in a first version? i think this would give us a good solid foundation to move forward from.

• Message Widget
• Horizontal Scrolling
• Find Command
• Optimize cursor rendering

This relates to #5.

I have a branch, fixes-for-protocol-changes, on my fork to work on this. I will probably also have to tackle the the scroll_to change to the protocol as well, since I just hit that snag.

I will have some free time later in the week, i have a local fork with this working with xdg, if your ok with the added dependency i can create a PR.

I would love to have a more sublime-text like terminal editor.
This project seems to drift more towards vim.
It might be possible to get both, if keybindings where completely user-configurable with a config-file like sublime does it.
Would you be interested in a pull request for something like this?

Goals:

1. Be able to simply copy&paste a sublime-keybindings file (of course most actions are not yet supported).
2. Generate one for the current state as well and make default
3. Safe those and user-defined overwrites (future step) under XDG-paths
4. Make all possible commands available via keybindings or Command prompt

Rough overview

Simple keybinding

	{ "keys": ["ctrl+q"], "command": "exit" },

More complex keybinding

	{ "keys": ["left"], "command": "move", "args": {"by": "characters", "forward": false} },
	{ "keys": ["ctrl+left"], "command": "move", "args": {"by": "words", "forward": false} },
	{ "keys": ["shift+left"], "command": "move", "args": {"by": "characters", "forward": false, "extend": true} },
	{ "keys": ["ctrl+shift+left"], "command": "move", "args": {"by": "words", "forward": false, "extend": true} },

This seems to be very flexible and I think would allow for a vim-like binding as well as sublime-like or maybe even emacs.

Code changes

For now, I would stick with the simple bindings first (although args is not hard to do with rust Enums):

1. Have a function that parses the value of "keys" to map to Event::Key(...)
2. Have a function that parses the value of "command" to enum Command
3. Enhance Command to encompass all possible commands
4. Create a global HashMap<Event::Key, Command> out of steps 1 and 2.
5. Rewrite the match-statements in Tui, Editor and Command to all map to the same functions

This might not be the direction you want to go, which is fine. If so, I would simply create a hard fork and diverge, if thats ok with you.

When cursor moves fast like on constant holding down key I see how xi-term blinks, like redrawing or something. Checked in Alacritty and xfce4-terminal. Is it a config issue or a bug?

Currently, we always open "test-file" for editing. Let's change that.