Vis: A Vim-Like Text Editor

[loudmax]

Kudos to the developers for listing non goals. Too many software projects lose focus and become bloated because they take on features that are secondary to the main purpose. Projects may refrain from listing non goals for fear of excluding people who may want some of those features.

And looking at the list, there are some pretty nice features excluded. For example network support, or editing compressed or tar files. I guess the expectation is that these can still be accomplished by leveraging commands outside the editor. This is a clean approach.

Okay, but no diff mode? vimdiff is fantastic! And I'm not sure how you recover that functionality without multiple workspaces. Maybe the answer is you don't. Use vis for normal editing and pull out vimdiff only when you need it.

[aoloe]

concerning vimdiff: one of the goal is to get vis to also work in server mode and be embeddable. it should then be possible to create a diff tool that uses vis for the editing.

[rbonvall]

The great thing about vim is that it'll always be there as a fallback.

I keep a file with my passwords, encrypted with Vim's builtin encryption. Neovim removed that feature. If I ever switch to neovim, I can still use vim when I need to open that file.

[vbit]

For a non-vim user - can you describe what vimdiff is please?

[xiaopingguo]

More people should definitely try out sam and 9term as examples of how much code/features you don't really need and can still get real work done.

Personally, I wish sam had even less complexity and features than it currently does and thus be more understandable and hackable. Also, never going back to a normal terminal again, "dumb" terminals are awesome.

And actually, this experience has lead to a philosophy of software where I think the "dumb"er a piece of software the better and more reliable/performant it is likely to be. So I'm also hugely skeptical of the current Deep AI efforts leading to anywhere good.

[Mossisen]

How would you compare this to the NeoVim project? https://github.com/neovim/neovim

[martanne]

Reposting an answer from a related thread.

The main difference is that vis is written from scratch while neovim inherited an old and hard to maintain code base. This allows vis to experiment with various ideas:

- native multiple cursors/selection support

- structural regular expression support

- different core data structure resulting in efficient large file support

- LPeg based syntax highlighting

- Lua as an in process extension language

- client/server design (not yet implemented)

without having to care about backward compatibility and legacy systems. Of course this has also some drawbacks for example there is no existing plugin ecosystem etc

[starseeker]

I note that with the exception of the sam code (which unfortunately uses the Lucent Public License Version 1.02, this editor is very liberally licensed (ISC/MIT/CC0).

If the sam code is optional or easily replaced, this could evolve to become a serious, modern text editor with a truly liberal license (something surprisingly absent from the current landscape, to the best of my knowledge - I've done a couple searches for an editor that could be embedded with an LGPL project, and the choices were pretty limited. This looks quite interesting.

From a portability standpoint, is there any chance of creating a native Windows version using something like http://www.projectpluto.com/win32a.htm ? That was another kicker when I was searching previously - only the really big editors like vim/emacs appear to have Windows ports...

[sdkmvx]

nvi? https://sites.google.com/a/bostic.com/keithbostic/vi/

Sure it doesn't have the features of Vim or Emacs (and some would say that's a feature!), but it's perfectly serviceable if you're okay with vi's modality.

[swah]

Go is a good target for portable text editors these days, IMO: https://github.com/nsf/godit

[woah]

Microsoft VS Code is MIT licensed.

[falcolas]

For a standalone piece of software, what about licensing matters for your use cases?

[tambourine_man]

Meta: I don't get HN's new deduplication algorithm. I submitted the same link yesterday.

https://news.ycombinator.com/item?id=11434195

[DanSmooth]

I noticed similar problems with medium.com links where the stuff after the inserted hashtag leads to multple submissions of the same link.

[pklausler]

Every good programmer should write their own text editor, I think, much as each Jedi must build their own light saber. It's the tool that a programmer will spend a disproportionate amount of their time using, and they should know it well. And it's fun to do, and easy (c. 7KLOC or so for mine).

[vbit]

Is your editor publicly available?

[StreamBright]

What would be the advantage of using it over vim? I am just curious. One thing I found is huge file support that would be definitely good but not sure about the rest.

[cloudhead]

The promise is that given it's a new, modern codebase, it could quickly outpace vim in capabilities and usability. Vim's legacy is what is holding the editor back from major improvements.

[jhallenworld]

I'd like to suggest trying integrating the syntax highlighter from JOE for speed, but JOE is GPL...

Also, I'm not sure how large the Lua/LPeg state is, but for JOE we found the highlighter is more accurate if you retain the state of each line (or every n lines), and start parsing from a real known state. It looks like Vis starts parsing 16K before the start of the window.

https://sourceforge.net/p/joe-editor/mercurial/ci/default/tr...

[martanne]

Thanks for the hacking file, it is a good read for people like myself who are interested in text editor implementations. If time permits I will try delve a bit into the joe code base.

As for the syntax highlighting in vis, yes it currently is stateless and only considers a fixed range of text prior to the start of the window. Having no state at all simplifies some things and allows vis to highlight even extremely large files at the expense of the occasional glitch. In practice it seems to work reasonably well.

This approach also requires that the highlighting is fast, because nothing is cached, it is completely redone after every cursor motion. I'm quite happy with LPeg so far, it is convenient to express grammars in a high level language like Lua. It also supports nested grammars nicely, but due to the completely stateless approach taken by vis this is currently not fully exploited. As an added bonus there were already ~100 lexers (of admittedly varying quality) available for use.

[isxek]

Thanks for writing the JOE editor. I've been using it for simple text editing tasks (commit messages, etc.) now that I've moved over to a Linux system. I appreciate its simplicity.

[ageofwant]

Excellent. The more vim the better. I would like to see many of the core vim patterns replicated in other editors:

  - modal over chords
  - text objects
  - the vim "language" which ties it together
  - all the other good stuff, did I mention text objects ?

There is a reason vim has more users today then ever before: once you learn the deceptively simple language you can have deep conversations with your editor.

[gnuvince]

The vim language would be better if it wasn't full of exceptions that have no reason for existing (e.g. `Y` is `yy` rather than `y$`, or `cw` and `ce` being equivalent while `dw` and `de` perform different actions).

[cyphar]

I actually like the fact that NeoVim is working on VimL to Lua translation so you can write plugins in Lua. Emacs has had LISP from the beginning. Maybe we can soon fight back with a real programming language.

[yoz-y]

I am very glad that most IDEs have either native or plugin based vim-modes.

[geowwy]

Sounds similar to Kakoune (http://kakoune.org/) but with Sam expressions

[martanne]

Yes from a design philosophy standpoint vis is closer to kakoune than {neo,}vim. The implementation is quite different though (no C++, no boost, no home grown scripting/extension/syntax highlighting language).

[irremediable]

One of these days, I'm going to sit down and try out this, emacs-evil, and neovim. Side-by-side. Need to figure out which one I like most.

[kromem]

I just switched from vim to neovim to evil. I can't see myself ever going back. (Neovim was basically just vim with async support, and terminals, but as a tmux user, that didn't really grab my attention).

There's a lot more polish in the integrations for emacs than vim, likely as a result of literally everything in the editor being a function call that can be hooked into.

The only thing I miss is solid tab functionality (there's a short of hack I've seen so far, but feels too rough for me). But honestly, with projectile + heap, I barely miss that.

Company-mode far outpaces the auto completion options in vim (though to be fair to the plugin authors, apparently they need to resort to major hacks to perform some of the things they do). Just as an example, when you autocomplete a function call, it populates the arguments and let's you tab through completing them. This same functionality sits as open tickets in the major vim autocomplete plugins, with a response of essentially "this is really hard to do in vim, hopefully we can figure something out in neovim".

It's worth the 2-3 days to make the switch and set yourself up. Also, a recommendation -- autostart emacs in server mode and use enacsclient to connect to that for all your editing needs.

[ExceptionRaised]

I feel you. I want to like neovim, I really do. Same thing with this. I even want to just use emacs+evil. But since I've picked up spacemacs (~3 months ago) I can't really use anything else. I'm already pretty hooked on orgmode, and the consistent keybindings that spacemacs provides are wonderful.

[bigtunacan]

This seemed interesting and I'm glad they posted their "Non goals". For me, and I would assume many others, plugins (which apparently is part of the 20% they don't plan to support) is one of the most critical features to any good text editor. This is one area where I think they may want to reconsider.

[exDM69]

"Plugins" can mean many things, ranging from dynamically loading parts of the app to having an embedded scripting language.

I'm fine with a text editor without plugins as long as the editor can neatly interface with external applications. I used to use some Vim plugins but I found them to be more trouble than they're worth. Now I have vanilla Vim with only some syntax highlighting additions.

Rather than embedding my workflows into the editor, I'd like to embed the editor in my workflows. I don't want to run terminal apps from inside the editor, but I do want to run external apps and get the results in the editor. E.g. Vim has :make and :grep that work with the quickfix list, but this can also be done by invoking make or grep in the shell and piping the output to vim (+ some command line options to read the quickfix from stdin).

For my use, the feature that Vis needs the most is the client-server model, so I can use tmux to manage windows and open editor windows in any terminal session. That, coupled with some helpers to run external apps should do more than 80% of what I'd use editor plugins for.

[SpaceCadetJones]

I imagine this would be a non-starter for a lot of people, it definitely is for me

[pttrsmrt]

But what does it got that vim doesn't?

[cturner]

Sam expressions for manipulating text. This is a blub thing - if you haven't seen them you might not realise what you're missing out on. Try to imagine an editor where the core idea is a better-sed-than-sed.

Two well-known editors to come from the ed tradition: vi and sam. Vi is an obvious evolution - make it 2d. Sam did this as well, but its main focus was developing the expression language. For example, so you can chain expressions together for text manipulation. Another comment mentions multiple cursors.

But sam also has plan9 culture. It strongly encourages the mouse with an interaction that I've found to difficult to adjust to.

Vis seems to unify the best bits of vi and sam, from a unix user's perspective.

If anyone reading this knows sam or vis fluently, it would be helpful to have a youtube video for each of sam and vis in the the style of the recent Russ Cox video on acme.

[I'm struggling to get this vis thing to build and run, tips? Debian stable. I downloaded libtermkey, configure, make make install. Not thrilled about this - would rather it create .a and .h files I could copy it into the vis dir. Now when I run ./vis it says, "error while loading shared libraries: libtermkey.so.1: cannot open shared object file: No such file or directory".]

[boomlinde]

The editor core is written in a reasonable amount of clean (your mileage may vary), modern and legacy free C code enabling it to run in resource constrained environments. The implementation should be easy to hack on and encourage experimentation (e.g. native built in support for multiple cursors). There also exists a Lua API for in process extensions.

[vim-guru]

Obviously, structural editing like that of SAM. Vim also does not have native support for multiple cursors.

[6d65]

Looks very good.

Definitely going to give it a try. Currently I'm using Neovim and I like a lot the embedded terminal feature. I wonder how easily this can be recreated using a Lua plugin.

[exDM69]

> I wonder how easily this can be recreated using a Lua plugin.

It's probably a better idea to use tmux/screen/dtvm for terminals rather than embedding a terminal in a minimal editor.

The TODO list mentions asynchronous event loops, that's necessary to do any plugins with external processes neatly.

[C0d3r]

That video needs sound, I have no idea about what's happening.

[martanne]

As the producer of the "video" (it is actually ASCII, you can copy paste stuff out of it) I agree, here is an annotated version:

    - x/pattern/  extracts stuff from the text, creates a selection for every match
    - some normal vi motions are used to modify the selections, "o" to move the
      cursor from one end of the selection to the other, "w" to move the cursor
      to the start of the next word
    - y/,/ similar to x/ but create a selection for everything which does not match,
      hence splitting the existing selection  into multiple ones
    - \ trim selections i.e. remove leading and trailing white space
    - v/Vis keep all selection not matching Vis
    - g/F|C keep all selection matching F|C
    - + rotate selection contents on the same line
    - v/Com keep all selection not matching Com
    - + rotate some more
    - ESC clear selections, ESC remove all cursors
    - x/pattern select different regions
    - .,/^\} extend selection by searching in forward direction until the first match
      of } at the start of a line
    - { i/#if 0\n/ a/\n#endif/ } insert some text before every selection with i/text/
      and append some text after every selection with a/text/
   
    - change file, select similarily indented code block using a text object: vi<Tab>
    - x/\w+ extracts all words from selection
    - Tab align selections
    - C-c remove first selection column (i.e. remove first selection on every line)
    - Esc clear selections, switch to normal mode, move to next { with f{
    - i<S-Tab> goto insert mode and align cursors

    - search a variable, select it with C-n
    - C-n select next match
    - C-x skip this match, that is clear it and select next match
    - C-n select next match
    - c vi change operator, delete selection, switch to insert mode
    - rename the variable, switch back to normal mode
    - undo the changes

[vim-guru]

That would indeed be helpful.

[doki_pen]

Why is this better than neovim? How many modern "vi"s do we need?

[dhoe]

Looks promising, and support for huge files is a weak point in vim, so I gave it a try. My usual workflow with big logfiles is to zoom into certain types of messages with e.g. :v/error/d and back out with u, and alternatively jump from one occurrence of a string to the next with *. That doesn't seem to work, so for the moment it's not the right 80% for me. But I do think it's a worthy project, so I'll keep an eye on this

[martanne]

Everything involving searching is currently probably very slow for large files, this is especially true for backward searches. The reason being that we currently rely on the regexp engine of libc and thus have to copy the underlying text to a contiguous memory area.

Navigating large files with motions like 50%, 70% should however be instantaneous. Navigating by line number is again somewhat slower, because the file actually needs to be read in this case.

Aside from that :v/ has a different meaning in vis.

[chris_wot]

What does :v do?

[notzorbo3]

I was gonna complain about the lack of binaries, which will instantly make me skip your project, until I saw this:

> On Linux based systems make standalone will attempt to download, compile and install all of the above dependencies into a subfolder inorder to build a self contained statically linked binary.

You'll still need the entire compiler toolchain, and 'libtool' on Ubuntu. I got as far as the ncursesw dependency before I gave up.

[martanne]

Yes the lack of binary packages is a known problem.

The whole project is still somewhat in flux, feel free to contribute by filling a packaging request to your favorite distribution ...

Historically it originates from a community which is comfortable building from source.

[zem]

from https://github.com/martanne/vis/issues/140 it seems like vis doesn't yet support language-specific autoindentation. this is a must-have feature for me; i'm surprised it wasn't more of a priority for them given that this seems to be targeting programmers.

[Philipp__]

This looks nice! Will keep and eye on it, give it a shot for few weeks when I finish with faculty.