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