xi-term
xi-term copied to clipboard
xi-frontend
make xi-tui a vim-like editor
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:
- https://github.com/google/xi-editor/issues/93
- https://github.com/google/xi-editor/issues/85
- https://github.com/google/xi-editor/issues/14
- https://github.com/google/xi-editor/pull/12
While I also love vim, I think the market for vim-like editors on the terminal is a bit crowded. :smile:
Mimicking the xi UI's keyboard shortcuts will make it easier to move between TUI and GUI.
Yeah that's right actually... I'll try Xi's native UI when I have a mac around, see how it feels and which shortcuts it's using.
What do you think the best way to mimic vim behavior with Xi would be? Should it be done in the core module, or in a specific front-end like xi-tui?
I can't see myself ever using another editor than vim/neovim, but if a project like Xi showed enough promise I would certainly help out or take charge of such an undertaking.
By the way, this is called modal text editor. And like @rosshadden I would love to reconsider Xi as my main editor if it would have modal editing mode.
I think that a frontend should be able to present both modal and combined editing modes.
And like @rosshadden I would love to reconsider Xi as my main editor if it would have modal editing mode.
:+1: from me as well
What do you think the best way to mimic vim behavior with Xi would be? Should it be done in the core module, or in a specific front-end like xi-tui?
The front-end seems like a good place to me, but I need to start implementing it to be sure.
Such plugins will be easy to implement later on in the life of Xi. I think it would be interesting to think of Vim like modal editing system for Xi instead of just replicating Vim as is. A clean slate could bring best of Vim and Emacs together. Vim's ability to let the user learn some basic commands and then combine them to form complex ones is it's greatest power. Xi needs to have a Vim inspired grammar IMO instead of direct Vim emulation.
@owais That's fair. I wonder if the best (and fastest) way to achieve this might be to make the editor APIs themselves very granular and composable, to facilitate powerful mappings.
That way we aren't just re-implementing vim, but at the same time are not heading down the impractical path of somehow recreating a similar magic, with key mappings and design choices that everyone comes to love. If done well, people could create a xi-tui-vim (perhaps community-driven), but still be able to make something more along the lines of what you are talking about as well.
Via the front end is probably easiest. After all, xi-core doesn't need to know that I pressed j to go down a line; it needs only know that the cursor has gone down a line.
I would, however, argue that in a modal environment, it would be best to keep the the default key bindings as superficially similar to vim as possible - primarily because you're going to have a very hard time getting vim users to learn a brand new modal editor when vim (or evil-mode on emacs) already does most of what they want. It's too much effort for (probably) not enough gain.
Both vim and emacs have long hand commands which can be typed out - and maybe xi front ends should as well. The key bindings could then be direct shortcuts to those commands, with the defaults given within an rc file (or other config file), which also contains whether or not the front end opens up as modal. That way, replacing or adding key bindings would be significantly simpler than needing to have a separate front end. This also opens up the possibility of allowing the front end to send those commands to a running plugin (via xi-core) - perhaps by means of "!plugin_name(command [arguments])" or similar syntax. Given the binding of keys to long hand commands, binding keys to commands within a plugin would feel more consistent with the rest of the editor.
@little-dude I'd love to help out with implementing some of this. I've started playing around with the codebase, but let me know if you'd like to coordinate efforts.
IMO https://github.com/slap-editor/slap is the benchmark on a good TUI (I assume this stands for text-ui?) editing experience. Highlights:
- first-class mouse support (even over an SSH connection)
- Modern keybindings (Ctrl+S = save, Ctrl+Q = quit, etc)
- syntax highlighting for 100+ languages
This makes it an absolute dream for editing files (e.g. config files) on remote servers over SSH. If you could make something like this that was reliable, performant and could be installed as a single binary without dependencies then I think you'd make a lot of people very happy.
The feature you mentioned has been merge: https://github.com/ticki/termion/pull/45
Any future plan for this project?
Any future plan for this project?
Yeah it's definitely not dead. I just work on it by periods, depending on my free time.
I just started to evaluate the possibility to replace the rpc code by something based on tokio. I made a crate for messagepack-rpc, and I'm thinking I could easily add support for xi's json-rpc protocol.
Once, this is done, I want to support styles, so that I can use Xi's highlighting, which is a bare minimum for a text editor.
Thanks @little-dude . Actually, I was looking for a minimum terminal-based editor written in pure Rust.
In case you missed it, there is also smith which currently has more features than xi-tui. I intend to catch up at some point though!
Thank you. I have tried Smith, it turns out that it relies on x11 which is a C/C++ libraries.
Actually, there's a way to combine both Emacs and Vim styles:
- Ctrl+Key works like a normal hotkey
- Pressing and releasing Ctrl switches the editor into command mode. Pressing Esc switches it back into edit mode
- Hotkeys are actually commands
So you can use xi like a normal editor but switch to vim style if you want to. By the way, it would be nice to support Sam style commands together with structural regular expressions.
