* Separation into front-end and back-end: NeoVIM does this. The UI uses the same interface a plugin does.
* Asynchronous operations: NeoVIM uses libuv to do this (same asynchronous C++ lib as NodeJS).
* Plug-ins over scripting: Yup, NeoVIM does this, as well as dropping vimscript (although it will compile vimscript into Lua for you).
* JSON: NeoVIM uses msgpack, which is significantly less overhead than JSON, but structure compatible.
The two other features listed are Rust and rope-structures, which are implimentation specifics that don't affect users or plugin writers at all.
Edit: The more the merrier! And it's good to see more projects using Rust, but I don't see this as a strong need. See https://github.com/rogual/neovim-dot-app for a nice native Mac UI plugin/client for neovim.
A large part of my motivation for starting this project is to explore how suitable Rust is for this kind of work. End users shouldn't have to care, they should judge it strictly by the quality of what it delivers. But I'm hoping this project will be interesting to Rust programmers for a number of reasons.
Well, when it comes to this new editor, doesn't it remain _even more_ to be seen?
At least NeoVIM has all the basics covered already.
They don't need it, but GUI can provide nice things consoles can't. For example real autocompletion drop-downs. Or see-through file outline/minimap like the one in sublime text. (https://2.bp.blogspot.com/-Co2awzuaA_s/TqQCZ1wwFLI/AAAAAAAAO...) Or better markers for things like region folds, column positions, matching braces, highlights, etc.
That said, I can't let go of modal editing, composeability, and word motions. Here's to hoping sublime implements them and I can relegate Vim/NeoVim to quick fixes in the terminal and Git commit messages.
There's no reason a TUI can't give you "real autocompletion". Vim does pretty well in most cases.
> Or see-through file outline/minimap like the one in sublime text.
I personally don't see the benefit of that, but you're right that you can't see a zoomed-out version of your code in a TUI.
> Or better markers for things like region folds, column positions, matching braces, highlights,
All of those things are supported by Vim and can be done in a TUI. As for "syntax highlighters" that decide to italicise code, I don't really consider that a feature.
As for markers, I know they're supported by Vim. That's why I'm saying better. For example Vim can't do single-pixel column marker (or specifically, create a line between columns). I can do hacks to highlight one column only (100th for example), but then highlight/copy on the terminal is broken, because in reality I just have spaces displayed after my code. Similar thing with region folds - they don't need to take the whole text row and the description of the fold can go off-buffer on a side.
Basically you can do everything with text. You can even print out "this is a placeholder for an image of a sad green frog looking at a computer screen". But actually displaying that picture is better ;)
Fair point, it's my biggest gripe with Vim's autocomplete--which I love. That being said when it works, it's more efficient than any other autocomplete I've seen in a text editor, since it's practically the shell's autocomplete.
> Basically you can do everything with text. You can even print out "this is a placeholder for an image of a sad green frog looking at a computer screen". But actually displaying that picture is better ;)
Once again, valid reasoning, but that's not the point. No one (at least I hope not) is seriously advocating TUI's for graphic design, we're talking about editing text, and that's where Vim excels.
What is the advantage of terminal based editors? As far as I can see, ubiquity, which is made less compelling when you need a host of plugins to do the things you mention.
Terminal editor enthusiasts seem to be under the effects of something like the Blub paradox, where any feature of a GUI editor described to them is dismissed with "why would I ever need that?" while anything in terminal emulator can do is considered essential.
Really? I'd like to see sublime handle text manipulations with the same efficiency and precision that Vim provides.
> What is the advantage of terminal based editors? As far as I can see, ubiquity, which is made less compelling when you need a host of plugins to do the things you mention.
What about integration with the shell? It's not merely a matter of ubiquity: I don't really need a document tree when I have the entire terminal at my disposal a :sh or :wq away.
> Terminal editor enthusiasts seem to be under the effects of something like the Blub paradox, where any feature of a GUI editor described to them is dismissed with "why would I ever need that?" while anything in terminal emulator can do is considered essential.
This would be an apt description if the majority of "terminal editor enthusiasts" were as inexperienced with GUI editors as their GUI counterparts, but in fact the opposite is true. Most Vim/Emacs users tend to have hundreds of hours experience working with GUI editors, but are for some reason convinced that they (the editors) were inferior. Finally, let me give you an irrelevant (but fun) fact: PG, the original proposer of the Blub paradox, uses vi.
I think you've misunderstood the claim here. The claim was not that all existing GUI editors do all the things that all existing terminal editors do. The claim is that a GUI (not a GUI editor, just a GUI) can do everything a console can do, and then do more things besides.
The claim is obviously true, because a GUI can embed a terminal interface in itself, and then augment it. I use emacs that way. It's emacs, but it also can do buttons, menus, proportional fonts, etc. (... not that I use any of those things, but it can), and all sorts of things it can't do in terminal mode even though it's literally the same executable. The point is that the GUI environment is intrinsically more flexible because the GUI has a superset of capabilities, not that a traditionally-GUI-centric design with heavy mouse and menu usage is superior.
The anecdotal suggestion that people who prefer a GUI simply don't know what they are talking about is just pure snobbery. I know both and I still prefer a GUI. You're right that the appeal to the authority of PG on this subject is irrelevant.
Can you give an example of an efficient/precise text manipulation that vim can do that sublime can't?
Because I rarely want to just "edit text" - >50% of the time I want to have a visual representation of the file tree with colored/graphical icons, drag & drop, etc.
A significant part of programming is organizing and exploring trough things, especially in huge code bases - GUI hands down beats any text based solution I've seen. This is also why I still won't use VS code as my go-to editor - no file icons - when I have a file tree with hundreds of nodes icons are the best way to find the stuff I'm looking for.
I keep wanting to try out Spacemacs but I always revert to Vim but it's pretty far from perfect imo.
Vim is more important as a way of text manipulation than as a specific program, and projects like NeoVim and Xi make Vim-the-way more portable and accessible. I would welcome editors that have a high-quality Vim experience and also have nice GUI features like mouse-over popups of function signatures, minimaps, or whatever a GUI unconstrained by the terminal can do -- rather than arguing for workarounds or why people don't need these features.
As a mouse user as well, sometimes selecting text with my mouse/positioning with mouse works fast, and I've always found text editors to not really be too great at letting me click accurately between characters.
Also, if you get into more IDE-y features, not having your "popup"s be overlayed colored text is usually a win for aesthetics. And hey, if I'm staring at something 8 hours a day, having it be pretty is nice right?
So even with GUI apps, I tend not to use the GUI. I don't think I'm alone. Virtually everything I run is either a terminal app to begin with or can run from the terminal. I have tmux set up to work almost exactly like my X window manager, so if I don't run X I barely notice. I'm just as productive without X window as I am with it except for a very few things: browser, gimp, a few games... Honestly I can't think of very much.
It's great that some people like GUIs. I used to use them a lot, but have since found that I'm happier without them. The keyboard is not really a discoverable UI device most of the time, but it can be ridiculously efficient once you learn how to use it. I also have very poor eyesight, so that probably predisposes me to using interfaces where I don't need to use my vision.
The mouse is never as powerful as vim commands. ;)
(Textual user interface)
Also most terms don't properly do utf8.
Maybe they want people to be able to easily distribute binaries of the software via BitTorrent. Apache allows this, the Vim License allows this, GPLv2 does not.
Another feature mentioned in the introduction is this:
* Developer friendliness. It should be easy to customize xi editor, whether by adding plug-ins or hacking on the core.
I'm vaguely familiar with NeoVIM, is the core "hackable"? This is really subjective territory but I'm guessing the author is implying that the xi core code is also optimized for human understandability and extensibility and that new code is judged by those criteria as well as the other stuff.
Regardless of my personal preference, I always found it odd: the back-end should be independent of what I perceive as an interface "detail". Even if, in this case, the detail is part of the software's identity.
Which is why I gladly welcome the xi project :)