Vis – A vi-like editor based on Plan 9's structural regular expressions | Hacker News Reader

Vis – A vi-like editor based on Plan 9's structural regular expressions

github.com

170 pointswooby39 comments

Open articleView on HN

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

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

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

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

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

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?

This was a better explanation for me: http://www.perlmonks.org/?node_id=665719

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

Thanks for that reminder. I've been using Acme for years, but I never figured out SREs.

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

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)

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.

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.

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

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.

Sounds like it's missing a few key features.

Yeah. I love vim's persistent undo. Combine that with the undotree[0] plugin and you never have to worry about losing changes.

It would be really hard for me to switch to an editor without persistent undo.

[0] https://github.com/mbbill/undotree

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

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

Why did you stop using it?

Emacs

Where does Guy Steele make this point? I'm curious to know the context, thank you.

https://mitpress.mit.edu/sicp/full-text/book/book.html

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.

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

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.

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

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

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

It is fast.

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.

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.

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.

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.

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

Yea same, full time kakoune user with no speed issues here. I will say that it has serious memory issues for large files tho, but that doesn't affect me normally.

Large as in massive tho, several hundred MB. Not my source code files, thankfully.

Any emacs mode that does a similar thing to this?

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

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.

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!