Hacker News Reader

Comment by fritzy | Hacker News Reader

According to the feature-set, this is basically NeoVIM.

* 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.

View on HN

NeoVIM is great, and obviously it has been inspiration. I think it remains to be seen whether NeoVIM can deliver an experience that feels like a modern editor. My experience is that projects which attempt to layer a GUI on top of an existing, mature console UI end up leaking bits of the underlying UI. I'm thinking mostly of the various TeX shells here.

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.

>NeoVIM is great, and obviously it has been inspiration. I think it remains to be seen whether NeoVIM can deliver an experience that feels like a modern editor.

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.

I don't understand why people need a GUI to edit text. And while I donate to the NeoVIM project, I don't really like that they are increasing incompatibility with Vim in order to create a GUI layer. It also bothers me that they didn't just use the GPLv2 (because I find the dual Vim-Apache licensing troubling).

Is your terminal program not a GUI? Or do you not run a graphical window environment at all?

Not the OP, but a lot of people (myself included) have minimal mouse interaction even when they use X-windows. For example, I use a tiling window manager and only interact with it through the keyboard. I use urxvt as my terminal emulator and while I suspect it has some kind of mouse support I have no idea what it is because I have never used it. I have my web browser set up so that as much as possible everything is controllable through the keyboard. I move all my windows around, resize, hide, focus with the keyboard. I don't have any menu bars at all. All of the apps I use I have hidden the menu bars if I can because I don't use them.

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.

TUI

(Textual user interface)

I use the mouse as little as physically possible, so I use a tiling window manager with nice keybindings. I usually only have a terminal and Firefox (vimperator) open, both of which don't require mouse usage. So, I don't get the idea of having a graphical text editor when you can just use one in the terminal (and you get the benefits of portability and working on something over SSH for free -- and no, X11 forwarding isn't a substitute).

The mouse is never as powerful as vim commands. ;)

I love GUIs. Oh dear god, sometimes I just want to click and highlight and drag things around.

If that's your thing, terminal emulators have had support for that for years. Vim and NeoVim both have support for it too.

Just tried drag-and-drop in my gnome-terminal. Didn't work.

What part of "click and highlight and drag things around" includes "drag and drop"? I'm not going to comment on drag-and-drop as being a useful feature (I don't consider it one), but it wasn't mentioned in GP.

I guess it's possible that GP meant "drag things around without any effect".

Drag and drop's pretty neat I reckon. Pretty nice when things tie into the native APIs in OS X so you can even drag snippets of text between applications. Pretty sure people would have shat their pants when they first saw that working in NextStep - it's nice not to break it.

Cause why not? I would love inline images to be displayed instead of opening links and all sorts of interactive contents.

That's not really "text editing" anymore. Also, if the "links" are remote objects (like URLs), that sounds like a whole heap of privacy and security issues.

Smooth scrolling alone makes me often opt for not-Emacs (running plain Emacs in OS X). I've tried several solutions to solve this from googling, never found anything that was effective.

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?

The emacs-mac on homebrew (https://github.com/railwaycat/homebrew-emacsmacport) by Yamamoto Mitsuharu has smooth scrolling and a bunch of other OS X niceties.

I like GUI's not because I use the mouse (I don't), but because the terminal is sub-optimal for presenting information. Yes, it's very portable but I don't need that, I only use my editor locally and on OS X. I despise having to install custom fonts to hack special UI elements like Airline. I like the mini-view in Sublime. I like my UI to be able to show me little hints without necessary taking up an entire character.

I keep wanting to try out Spacemacs but I always revert to Vim but it's pretty far from perfect imo.

>I don't understand why people need a GUI to edit text

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.

Why use a file tree when you have a terminal? It's been shown to be the most effective (and before you shoot, by "effective" I mean fast) way to manage files, and that way you can do advanced searching through whatever code base you're using. Plus you can access all the other awesome tools (like Git) for managing your project.

1. I forget exact file names in large codebases. I'm using the visual representation to jog my memory. 2. It's easier for me to remember where an infrequently-used command is in a menu tree than it is to remember the command. It is faster for me to scan through a menu than it is for me to go to stack overflow. 3. This is clunky: https://groups.google.com/forum/#!topic/vim_mac/YUrhWQvlTRA and I don't know that it's any better on any platform. 4. My editor should be able to handle an interface to git as well. I have a plugin for it and MacVim personally.

> I don't understand why people need a GUI to edit text.

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.

> For example real autocompletion drop-downs.

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.

By real autocompletion dropdowns, I mean dropdowns which are different from editing buffer. That means whatever is the colour of the code/background underneath, they won't blend in in confusing ways. VIM does coloured completion drop-downs, but they're still just buffer-like text. Unless you mess with your theme manually, there's a chance it will blend in and confuse you one day, because there's no real frame around it.

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 ;)

> By real autocompletion dropdowns, I mean dropdowns which are different from editing buffer.

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.

A GUI editor can do everything a terminal based emulator can; there are lots of things a GUI editor can do that a text editor can't. Some examples were given in another reply. Others include inline previews of things like latex equations or images, documentation tooltips, unobtrusive autocomplete popups, proportional fonts, proper mouse interaction, working well with window managers, and basically complete freedom to design the interface in a way which is optimal for whatever task rather than shoe-horning it into a grid of text.

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.

> A GUI editor can do everything a terminal based emulator can; there are lots of things a GUI editor can do that a text editor can't.

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.

"Really? I'd like to see sublime handle text manipulations with the same efficiency and precision that Vim provides."

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.

Your first two points are simply features, and there is no reason they can't be implemented for GUI editors. In fact they are available for many of them.

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.

>Really? I'd like to see sublime handle text manipulations with the same efficiency and precision that Vim provides.

Can you give an example of an efficient/precise text manipulation that vim can do that sublime can't?

I don't think you've mentioned a single thing that can't be done by Emacs/Vim, with minimal customization. Personally I use Vim, which has great auto-completion (it's minimalist and extremely effective), extremely customize-able code-folding, highlighting and advanced navigation features out of the box. With a few plugins (like the NERD family, Syntastic etc.) it has all the features you mentioned, along with having insanely good performance and integration with the shell. And that's not to mention the advanced editing capabilities it has for managing text, which far exceed those available in editors like Sublime.

I've never experienced this "insanely good performance" from Vim or NeoVim. It's fine for editing code when lines are short, but as soon as the lines get long or the file itself it's long, or if I'm using all of those plug-ins necessary to replicate basic functionality in Sublime, it slows down substantially.

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.

They don't. But people usually do more than mere text editing. With emacs I read PDFs and look at images.

Also most terms don't properly do utf8.

There are a lot of benefits that people don't need, such as the benefits which are unique to the terminal and somehow not feasible in a GUI. Most people have a work machine that's powerful and can have an editor of their choice installed. Why be constrained to the terminal?

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.

> It also bothers me that they didn't just use the GPLv2

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[0].

[0] https://www.gnu.org/licenses/gpl-faq.html#BitTorrent

Well, it could also be used under the terms of the GPLv3 (because the Vim license allows you to license it under the GPLv2 or later). Most people don't like the GPLv3, which is why I didn't mention it (even though it is a superior license in many ways).

Correction, GPLv2 or later. GPLv3 is better than GPLv2 in several respects and the Vim license lets you license under any later version of the GPL as well. :D

I think the overlap in features demonstrates popular appeal for such features in our tools. I think the details of how they're implemented are pretty important to users too so there's space for innovation even if the feature set is the same on the surface.

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.

In line with your JSON bullet point, I think this project should adopt a smaller/binary data transfer format. Having something that's human readable isn't of that much value in this case, where maximising speed seems to be the goal.

About NeoVIM I agree with everything except for the fact that - if I'm not mistaken, but maybe I am - the back-end is still tied to the VIM key bindings & modes. I don't think they plan on changing that.

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.

Yes and no. NeoVIM is tied to key bindings as much as VIM is (so you can rebind basically anything). But yes, they basically redo VIM, so modes are definitely staying.

Thanks for the clarification. What I perceived, and maybe should have said above, was simply that it would be hard for me to make a simple GUI front-end which would follow CUA, for instance, while leveraging the solid back-end.

Which is why I gladly welcome the xi project :)

If my car has those same features, is it basically NeoVIM, too?

I don't think the comment associating Xi with NeoVim is that critical. It's more of a quick mental summarize-and-compare that other people would've performed as well when peeking at the project.

GP's point was that GGP doesn't say anything about what the project actually does or how it's UI works.

Reply on news.ycombinator.com