What does HackerNews think of vis?
A vi-like editor based on Plan 9's structural regular expressions
> Small and understandable core.
> Proficiency with POSIX tools, and maybe even some programming languages other than sh.
> Structural regular expressions as a central way of text manipulation.
> With multiple selections created via regular expressions, acting upon regular expressions.
> Fresh take on the modal editing paradigm.
I wonder if the author has ever heard of vis[0] which imho fulfills far better each one of those premises
As far as conventional editors go, I'm a big fan of vis. Multiple cursors, structural regex, and vi keybindings are just too nice to give up.
https://github.com/mg979/vim-visual-multi
I do wish it was built in (like in vis) though
Another example might be my favorite text editor, vis[1].
[0] https://www.openbsd.org/ [1] https://github.com/martanne/vis
I feel more comfortable with it than sam's given than I'm not as much as a mouse person but a keyboard person (even though being a graphic designer). It's development is not as heavy as is stuff like neovim or kakoune, but still at this very moment I find it usable, quick and reliable.
> Vis aims to be a modern, legacy-free, simple yet efficient editor, combining the strengths of both vi(m) and sam.
https://github.com/martanne/vis
"Differences from Kakoune": https://github.com/martanne/vis/wiki/Differences-from-Kakoun...
I wonder how these two compare?
[1] https://github.com/martanne/vis [2] http://doc.cat-v.org/bell_labs/structural_regexps/
[^1]: These structural regular expressions took me a bit to get used to, but by now I really like the concept.
This is why I switched to vis (https://github.com/martanne/vis) after trying kak for a couple days (and previously being an nvim user). ^k and ^j add cursors directly above and below the current one, :x/foo/ selects all occurrences of ‘foo’ in the current selection or (if there’s no current selection) file (this is based on the command language of Rob Pike’s `sam` editor, and foo can be a structural regex), and then you can manipulate them using standard vi bindings.
(Edit) I learned vim a little bit over a year ago, switched to neovim soon after, tried kakuone for a few days and didn't like losing so much muscle memory because of the verb-noun order reversal, switched to vis a few months ago and don't plan to switch back.
1: https://github.com/martanne/vis 2: https://en.wikipedia.org/wiki/Sam_(text_editor), http://sam.cat-v.org/
Also, using structural regexps for efficient interactive text editing: https://github.com/martanne/vis
The video in the README.md is impressive, and together with the PDF document linked above even I'm going to be able to figure this out.
vis-menu is distributed with vis: https://github.com/martanne/vis
This project seems fine as well; though the examples seemed a bit complicated to me. I guess I'll need to rtfm.
The structural regular expressions are also pretty interesting.
I did try "vis" a while ago and it was alright but not quite there yet. And it was a bit too "sickness" for my taste, e.g. requires shell scripts for completion to ":open".
I do intend to try it again some time but I'll also give kakoune a go.
Having said that, if you like both vi(m) and the structural regular expression support of sam/acme you might be interested in vis which combines the two:
https://github.com/martanne/vis
It already has Lua extensions.
Or I might play with a pure python editor
https://github.com/jonathanslenders/pyvim
which is based largely on prompt_toolkit that iPython just adopted
Both editors are "vim like".
While the human readability of JSON is nice, it has some serious flaws when the goal is to handle arbitrary data.
I have yet to decide what kind of protocol to use in my own vis editor[1], hence why I'm asking.
> QBE aims to be a pure C embeddable backend that provides 70% of the performance of advanced compilers in 10% of the code.
This philosophy is very similar to that of vis [1], a vim-like editor that aims to have 80% of vim's functionality in 1% of the code. I hope that more such project see the light of the day; I'm very interested in simpler programs and simpler ecosystems, even if that comes at the cost of features.
printf "foo\nbar\nbaz\n" | vis - | sort
dvtm uses this mechanism to implement its copy mode.I also recently integrated sam's structural regular expression based command language into the editor. This might be useful for people who want the power of stream editors but with instant visual feedback.
However keep in mind that this feature is relatively new thus likely still contains some bugs ...
Anyway I didn't mean to discourage you from working on your project.
I just would like to use a decent terminal recording solution to showcase some of my own projects (e.g. abduco+dvtm, vis[1]). Ideally it would support:
* copy pasting from the screen cast
* pausing / adjusting playback speed
* simple self hosting mechanism
* conversion to gif as preview for inclusion in Markdown files or for environments where Javascript is disabled
* overlay to show pressed keys
AFAIK all but the last point is possible with asciinema. In the past I've used mkcast[2] which uses a fork of screenkey and is a pain to use. Apparently its developer now recommends xscast.
Anyway it is a mess to use and as a result the featured screen casts for my projects are rarely updated and by now completely out of date.
- from what I've read somewhere, MS Word was/is (?) using it internally [http://1017.songtrellisopml.com/whatsBeenWroughtUsingPieceTa..., ]
- AbiWord [1]
- [1]: http://www.catch22.net/tuts/piece-chains
- https://github.com/martanne/vis
- the text editor of the Oberon OS used it [1]
One of its most intevesting advantages is that it trivially supports fast unlimited and persistent undo/redo
First of all, session support and terminal multiplexing are two distinct features which shouldn't be intermingled. What ever happened to the Unix principle of doing one thing and doing it well? My take on this problem is a combination of abduco[1] and dvtm[2].
Next a built in copy mode seems wrong, there is no need to implement vi(m) or emacs key bindings when you can make use of the complete editor. That is why dvtm uses my vim clone vis[3] as a filter: the terminal (scroll back) content is piped to $EDITOR and whatever the editor writes to stdout is kept in a register to be pasted in other terminal windows.
Furthermore I think the completion menu should also be implemented as a standalone tool (using e.g. dmenu or slmenu) as is done for the vis file open dialog.
As a last point I consider Pyhton not really suitable for core system tools, if you want something more expressible than C then something like Rust would probably have been a better choice.
[1] https://github.com/martanne/abduco [2] https://github.com/martanne/dvtm [3] https://github.com/martanne/vis
I spent quite some months learning about editors and one of my evening distractions was to write a new UI backend for qemacs. I found the design clever, quite flexible, etc, but in no-way easy to read or elegant. (To be fair, it did not help that he added a video player and a WYSIWYG html editor to it).
Later I came to a Vim clone called vis (https://github.com/martanne/vis) and I found the source code more close to those programs where you think "It can't be made simpler".
I wish future programmers read more code before writing just like literature writers do. It should be part of the education system and I regret not having read "classics" before starting writing.
https://github.com/martanne/vis
As for the copy mode, in my opinion the multiplexer should use the editor as a filter (which requires that the editor uses stderr for its regular output). The whole scroll back buffer is piped to the editor and whatever the editor writes to stdout is kept around in a copy buffer.
That is the way it is implemented in the latest dvtm releases.
That is why I started from scratch: