
Vis – A vi-like editor based on Plan 9's structural regular expressions - wooby
https://github.com/martanne/vis
======
gwn7
I've been using vis as my primary editor for six months, and I'm quite happy
with it. (I'm a long time vim user.)

Main selling points for me:

\- Simple editor, easy to learn, with a ~650 line man page as the
documentation

\- Simple, yet has the most useful features from the great vim and sam editors

\- No feature bloat - unlike vim

\- No vimscript (lua instead)

\- Readable and hackable codebase - unlike vim

\- Structural regular expressions

For now the unavailable features that I miss the most are tag browsing and
code folding. I don't miss them very much in sufficiently clean and modular
codebases, but they are indispensable when analyzing large, complex, or badly
written code. I switch to vim when that is the case. I should say that their
implementation is considered though:

[https://github.com/martanne/vis/issues/547](https://github.com/martanne/vis/issues/547)

[https://github.com/martanne/vis/issues/342](https://github.com/martanne/vis/issues/342)

vis is highly recommended to anybody looking for a better vim and appreciate &
know how to use vim without a gazillion of plugins.

~~~
wooby
Not sure if this is what you meant by tag browsing, but I've been using
[https://github.com/kupospelov/vis-ctags](https://github.com/kupospelov/vis-
ctags) successfully today.

~~~
gwn7
Yes this is exactly what I meant. Thank you for letting me know!

------
pmoriarty
Anyone interested in what structural regular expressions are and how they're
superior to ordinary regular expressions is encouraged to read:

[http://doc.cat-v.org/bell_labs/structural_regexps/se.pdf](http://doc.cat-v.org/bell_labs/structural_regexps/se.pdf)

~~~
norswap
After glancing through this document, I'm still not sure what they are. The
document seems to describe a _use_ of regular expression rather than a new
form of regular expression. Am I mistaken?

~~~
tyingq
This was a better explanation for me:
[http://www.perlmonks.org/?node_id=665719](http://www.perlmonks.org/?node_id=665719)

~~~
gbrown_
I'd only seen Rob Pike's stuff before so thanks for sharing this!

------
doozy
This is an excellent vi-like editor. I've been using it for a while as a
lightweight vim alternative and have few complains.

The name choice is unfortunate, as it clashes with the vis(1) command, which
has existed since 4.4BSD

~~~
emmelaich
Yes, and the BSD _vis_ is part of MacOS which quite a few people use.

There was a homebrew package for 0.2 but it was deleted. Not sure if was
replaced with a different name.

How about _vi9_ for a name? Or _Vine_. Pretty easy to type since the 9 is just
above the i on the keyboard. (qwerty)

~~~
doozy
If being easy to type is the criteria, I would suggest vij, vio, vil, vid or
via, since that's where your fingers are likely to be after typing vi if you
are touch typing.

------
PuercoPop
I used Vis full time for a two weeks a couple of months ago. It was pretty
nifty. (I'm Emacs user so this was an time-bounded experiment).

Vis is a great of example of the suckless philosophy and of Guy Steele's point
about removing the need of features by having synergy between other features.
For example they have an immutable piece table to support undo by just moving
a pointer. This would mean that as the buffer remains open one would use more
and more memory. Instead of implementation a 'garbarge collector' they chose
to automatically close a file when its not shown on the screen.

~~~
tetrep
> Instead of implementation a 'garbarge collector' they chose to automatically
> close a file when its not shown on the screen.

Does that mean you lose the ability to undo actions when you switch buffers?
That sounds horrible if you're editing multiple files.

~~~
gwn7
That's not the case, as there are no hidden buffers in vis. If a file is open,
it is shown on the screen as either a horizontal or a vertical split. That's
the only way to edit multiple files.

~~~
luvbb
Sounds like it's missing a few key features.

~~~
gwn7
The only missing feature that is being mentioned here is the "hidden buffers".
Undo is working properly.

A related comment on buffer management from the author of the project:
[https://github.com/martanne/vis/issues/300#issuecomment-2160...](https://github.com/martanne/vis/issues/300#issuecomment-216034775)

I managed to live without hidden buffers so far, though I accept that they are
convenient.

------
RIMR
It always amazes me that Plan 9, which is widely regarded as a joke OS, has
continues to inspire new software with the different way it did just about
everything.

I have P9 VM, and I have never quite understood what I am doing with it, but I
keep hearing of developers borrowing from its codebase to make exciting new
software.

I also find SSSPC and TempleOS to be entertaining OSs to explore, as they are
so very different from the OSs I am used to.

~~~
abrowne
Who thinks of Plan 9 as a "joke OS"? It's obscure, sure, and has a jokey name,
but is hardly a joke itself.

~~~
RIMR
I guess the joke name combined with the fact that the OS has never really been
implemented in a serious capacity makes the whole thing seem kind of like a
joke.

It's really an experimental OS that was designed as a proof of concept more
than an actual product.

Nothing wrong with that, but if you find a computer running Plan 9 it's rarely
for a good reason.

~~~
eadmund
> the fact that the OS has never really been implemented in a serious capacity

I don't think that's true. It was briefly used as the OS for Lucent routers,
wasn't it?

I think it was meant to be a serious OS, and I rather wish that it had taken
off. Many of the problems of modern server systems simply don't exist with it.

------
gbrown_
A nod to Data Structures for Text Sequences by Charles Crowley as Vis utilizes
the piece chain.

[1]
[https://www.cs.unm.edu/~crowley/papers/sds.pdf](https://www.cs.unm.edu/~crowley/papers/sds.pdf)

------
fiatjaf
Is it faster than kakoune? I tried switching from vim to kakoune a while ago,
but it was horribly slow.

~~~
sevensor
I'm curious as a full-time kak user, what was slow for you? I haven't found
speed to be a problem with kak.

~~~
fiatjaf
I don't remember specifically, but I guess everything was slower than vim,
even normal typing. Maybe it used more memory too. My computers are probably
much older and weaker than yours, so I notice these things more than normal
people.

In any case, the slowness in comparison with vim was very small, I guess I
overestimated it in my previous comment.

~~~
sevensor
Fair enough! It may be that you built kak in debug mode? I could see that
slowing things down. I use kak on a variety of systems, including a six-year-
old netbook, so I do get a pretty fair sampling of the performance spectrum.

I was curious, so I ran an unscientific test. This is resource utilization as
reported by top.

    
    
        PID USER      PR  NI    VIRT    RES  %CPU %MEM     TIME+ S COMMAND
        
        1152 ~~~~~~~+  20   0  146.9m  77.0m   0.0  0.5   0:00.57 S          `- kak file0.csv
        1319 ~~~~~~~+  20   0  165.0m  94.4m   0.0  0.6   0:00.23 S          `- nvim file0.csv
        1333 ~~~~~~~+  20   0  249.5m  79.2m   0.0  0.5   0:00.18 S          `- vim file0.csv 
        1355 ~~~~~~~+  20   0   90.3m   5.3m   0.0  0.0   0:00.01 S          `- vis file0.csv 
    
    

file0.csv is a 58MiB csv file I made to test large file handling in another
application. Each line is at least 10k characters.

To push the limits, I tried to convert commas to spaces with a naive global
search and replace. There are approximately 4 million commas in this file. Kak
totally chokes on "%s,". Both nvim and vim do fine. Vis not only chokes but
consumes a huge amount of memory and needs to be killed with -9.

I run Arch, so I have old-fashioned vi available as well. Vi cannot open files
this big.

~~~
fiatjaf
Ok, so what is the conclusion? kak is almost fine, at least better than vis?

I did build kak in debug mode (but that was only because I had problems I was
trying to debug and get help with on the kak IRC), so maybe I'll blame that
and try kakoune again some time.

~~~
sevensor
> Ok, so what is the conclusion? kak is almost fine, at least better than vis?

I wouldn't say that -- the way vis does regex is pretty neat. I'd say all the
editors have limitations. Vim is super efficient for global search and replace
because after all these years it's still ex underneath, and ex is good at that
kind of thing. Vis and kak choke on my ridiculous global search and replace
test because they both want to create four million cursors at once. But on the
other hand, vis needs the least memory if all you're doing is opening the
file, and it seems pretty snappy for ordinary editing tasks. I'm sticking with
kak because I'm addicted to selection-oriented editing.

------
zitterbewegung
Any emacs mode that does a similar thing to this?

~~~
mhd
Most regex engines (including that in emacs) support multi-line expressions,
so that part is covered.

A loong time ago I found a package on Usenet that emulated sam's command
language. I found something on github[1] that seems to be a recent
modification of that, but I haven't tested it myself (last time I loaded
sam.el was in Emacs 19.34, back when I was actually using sam to do C
programming).

[1]: [https://github.com/realwhz/sam.el](https://github.com/realwhz/sam.el)

~~~
co_dh
That's why I like emacs. It has anything you can image. Due to the beauty of
elisp, people have fun to write in it, and thus contributed to the ecosystem.

------
jaytaylor
I'm unable to get it to build on a mac. Wish there was a pre-built binary
available so I could try it out!

------
PeachPlum
See also ports of plan9's Sam

[http://sam.cat-v.org/](http://sam.cat-v.org/)

