
Vis: A Vim-Like Text Editor - fractalb
https://github.com/martanne/vis
======
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.

~~~
geoelectric
So instead of the vim philosophy of embedding every functionality within vim,
this potentially embeds vis in every functionality? I actually like that--much
more composable.

~~~
qu4z-2
I believe (and I may be wrong) that the vim philosophy is actually to embed
vim in things rather than embed things in vim. They've just lost track of that
a little over time.

See also _:help design-not_ : 'Vim is not a shell or an Operating System. You
will not be able to run a shell inside Vim or use it to control a debugger.
This should work the other way around: Use Vim as a component from a shell or
in an IDE. A satirical way to say this: "Unlike Emacs, Vim does not attempt to
include everything but the kitchen sink, but some people say that you can
clean one with it. ;-)"'

~~~
geoelectric
You're right, and I sold vim a little short there, compared to something like
emacs.

More accurately, I meant that when someone wants to combine vim with a
functionality they tend to implement it as a plugin with vim as the host and
interface. I won't speak for anyone else, but my vimrc tends to accumulate a
lot of behavior such that it's still a kitchen sink--it just wasn't included
with the initial distro.

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

~~~
mhd
9term/Unix is still not as lean as something you'd get with a more integrated
environment like Oberon or Lisp. Just think of the many ways of parsing
arguments and input. Ad-hoc languages wherever you look.

~~~
cm3
Exactly. When you want to exchange data, it's much preferable to have
typed/tagged representations. If not that, then one should strive to at least
avoid regex "parsing" everything. The exception is that plumbing is okay
because it integrates output from all kinds of programs that already exist,
but if you have control, it's a lot better to have short prefixes like, say,
bug:BUG123, git:COMMITID, pkg:DISTROPACKAGE, etc. But these short prefixes
miss namespacing. Anyway, this is only true for acme and friends and in Oberon
elements are rich and not plain text.

------
Mossisen
How would you compare this to the NeoVim project?
[https://github.com/neovim/neovim](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

~~~
aktau
Great! I remember last time I looked at Vis it wasn't so far along (it had no
Lua integration AFAIK).

When I started submitting code to Neovim my biggest desires for it were (1)
Lua extensibility (2) A clean codebase (3) Compatibility with (most) Vim
plugins.

Perhaps ZyX-l's Vim to Lua project (for Neovim) could help with (3) at some
point, if that's desired.

An LPeg based syntax highlighting was also something in the back of my mind,
though way down the priority list. Fantastic to see it implemented, it truly
is the right choice (Neovim uses Corsix's C99 LPeg parser for its testing
framework, automatically exposing headers in a way LuaJIT's FFI groks).

Does it build with LuaJIT? (Sorry for the perhaps stupid question, I've just
glanced at your comments here and the terminal "video".

Keep up the good work.

~~~
mbrock
Does this kind of PEG parser deal somewhat decently with partial or incorrect
syntax trees?

~~~
vbit
The parser will match the specified grammar exactly, like it should. You could
of course specify a grammar that is broader than the actual language you are
parsing.

~~~
mbrock
Well, I am vaguely aware of the existence of "incremental parsers" and
"tolerant parsers", and a code editor necessarily works on code that's only
partially correct...

------
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](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/](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.

~~~
starseeker
Close, but it doesn't appear to be active (the version you get from the
download link is from 1996?) and it's using the 4 clause BSD license, which
(as I understand it) poses GPL compatibility problems.

------
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](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.

~~~
bootload
_" similar problems with medium.com links where the stuff after the inserted
hashtag"_

I always strip anything after the hash, checking the link still works. Medium
adds this info, in my opinion, for tracking.

~~~
ChrisGranger
If you're a Chrome or Firefox user, there's an add-on that can do this for
you.

Chrome: [https://chrome.google.com/webstore/detail/pure-
url/mphlceppe...](https://chrome.google.com/webstore/detail/pure-
url/mphlceppeighhlbggdkmcoieeckjnfjj)

Firefox: [https://addons.mozilla.org/en-US/firefox/addon/pure-
url/](https://addons.mozilla.org/en-US/firefox/addon/pure-url/)

------
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?

~~~
pklausler
Sure: [https://github.com/pklausler/aoeui](https://github.com/pklausler/aoeui)

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

~~~
lolsal
It sounds like you are saying it is better just because it is being written
from scratch. I don't plan on contributing or writing any plugins to Vis (or
vim) so I don't really care about what the 'guts' of the project look like as
long as it does what I use it for (text editing). What motivation would I have
to install Vis and deal with the mental overhead of switching (I am sincerely
asking)? I have the same concerns with NeoVim. Maybe I just need to wait a
decade for the ecosystem to catch up.

~~~
cloudhead
Yes. I would absolutely not advise to switch over at this point in time,
unless you want to support the project. In its current state, I suspect it
will be a poorer experience than vim and neovim.

------
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...](https://sourceforge.net/p/joe-
editor/mercurial/ci/default/tree/docs/hacking.md#syntax-highlighter)

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

~~~
lewiscollard
I shall add to your thanks. Joe's the first thing I install on any new box or
server and has been my default "quickly edit this thing" editor for a decade
and a half now.

Thanks, Joe author!

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

------
geowwy
Sounds similar to Kakoune ([http://kakoune.org/](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).

~~~
cm3
I don't use either, but to be fair, I wouldn't call vis's requirements lighter
than kakoune. Vis needs Lua and libtermkey (which according to its author is
EOL'ed) at build and run time.

~~~
martanne
Kakoune is a fine editor.

Regarding vis, Lua is optional (you lose syntax highlighting though).
libtermkey is a 3 file library and despite what the author claims it works, is
useful and could be maintained in the vis repository if necessary.

If you think anything C++ related is lighter than something C based, then we
just have to agree to disagree.

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

~~~
pka
I tried out evil some time ago, and while it was very nice, it glitched out
regularly - I would (mis)type a key combination and suddenly I'm dropped to
Emacs and feel completely lost. Has this happened to you?

On a side note, one of those days I'll just have to drop everything for 2
weeks and just learn Emacs.

~~~
Scarbutt
sounds like PEBCAK to me.

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

------
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".]

~~~
imurray
If you have libtermkey.so.1 somewhere, you could export LD_LIBRARY_PATH to
point to the directory containing it.

More notes on what to do if a build system for a project doesn't link in
libraries, and you can't simply install the relevant -dev package through apt-
get:
[http://homepages.inf.ed.ac.uk/imurray2/compnotes/library_lin...](http://homepages.inf.ed.ac.uk/imurray2/compnotes/library_linking.txt)

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

~~~
6d65
Well. Having a terminal as a buffer makes it possible to copy/paste into/from
the terminal.

Also autocomplete from all the buffers is working. It's really convenient.

And implementing a repl integration is trivial.

~~~
mbrock
You can also make a command that inserts a file into the current tmux buffer,
which is technically a much more straightforward solution than reimplementing
terminal emulation, I think.

~~~
6d65
Fair enough. Though, I've tried vim/neovim inside a tmux session, and the
terminal in neovim. And I find the latter(my personal opinion) to be more
fluent to use.

There's only one .nvimrc to manage as opposed to also, tmux's file. Also, when
I was using it, tmux it didn't support 24bit colors.

Again, that's a trade off, for the maintainer of the editor, it makes sense to
make it as simple as possible. But this means that the user of the app will
have to manage a part of the complexity, of setting up and maintaining a tmux
instance.

About terminal integration, I think neovim does it by embedding libvterm,
which takes care of handling the terminal part. This might be an
oversimplification though.

~~~
exDM69
> There's only one .nvimrc to manage as opposed to also, tmux's file.

Yes, this is definitely a trade-off.

I tend to have a global .vimrc and .tmux.conf with some sensible default
settings and on top of that, I do ad-hoc _per project_ config files that have
keybindings and other definitions unique to the project configuration. E.g.
run a certain test suite with a keypress.

The neat part in this is composability. The editor is just a component that
you embed in your tmux. You might have other "components", such as a debugger
or REPL or a file browser (ranger/midnight commander) in there too. This
doesn't work as nicely if the "top level" is a text editor.

I'm really fond of building these per-project ad-hoc "IDEs" out of terminal
and editor windows because I work with a really diverse set of languages and
tools and no single IDE or editor plugin suite would cover all my use cases
without hurting the others.

~~~
6d65
> There exist plans to use a client/server architecture, delegating window
> management to your windowing system or favorite terminal multiplexer.

This is from Vis's Github page. It looks like Vis's author thinks the same way
as you. And I get it, it's the Unix philosophy. Though the embedded terminal
is the single biggest feature I chose Neovim, over Vim. And that's just my
opinion.

Will give it a try though, to Vis, and some terminal multiplexer. See if I can
make it work.

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

~~~
yoo1I
> it is actually ASCII, you can copy paste stuff out of it

No offense to your texteditor, I'm a vim enthusiast and after installing vis
just now I really liked it, but that I can copy paste from that screencast
caught me really off guard, and it's the height of my day today.

Sure, in _hindsight_ it seems __obvious __, but ... that 's pretty cool!

... not sure what that says about me, maybe I don't wanna know.

thanks for pointing my eyes that way!

~~~
i336_
I say it says you're an engineer. :D

Only engineers see stuff like this and go "aw, cool!"

Incidentally the "video" is a small pile of JSON - filter for XHR in the
devtools to find it, the URL uses an expiration system so a direct link would
break. (Aaaand I just learned they implemented VT100 in JavaScript... the JSON
is full of actual, real, escape sequences...)

(If you haven't seen it, you might also like: [https://github.com/TheMozg/awk-
raycaster](https://github.com/TheMozg/awk-raycaster) /
[https://news.ycombinator.com/item?id=10896901](https://news.ycombinator.com/item?id=10896901))

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

~~~
chris_wot
What does :v do?

~~~
efaref
:help :v will tell you:

:[range]v[global]/{pattern}/[cmd] Same as :g!.

Where:

:[range]g[lobal]!/{pattern}/[cmd] Execute the Ex command [cmd] (default ":p")
on the lines within [range] where {pattern} does NOT match.

So :v/error/d will delete all lines that don't contain the string "error".

~~~
creshal
Which neatly maps to grep's -v option that does the same.

~~~
amelius
I always thought "-v" meant "verbose" traditionally in Unix command line
options.

~~~
creshal
No tradition without exceptions.

------
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](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.

------
msimpson
Tabs should not be a "non goal" if you support window splitting.

------
be21
Probably I am wrong but there seems to be no folding support?

