What does HackerNews think of vis?

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

Language: C

#2 in C
#1 in Lua
#1 in Vim
> Kakoune gives you:

> 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

[0] https://github.com/martanne/vis

You can try vis [0]. It incorporates Rob Pike's structural regular expressions and modal editing from vim. The very best of both worlds. Have been using it for a while and haven't looked back.

[0] https://github.com/martanne/vis

If you want an editor that uses Sam's structural regexes with keyboard-focussed vi-style interaction, you might be interested in https://github.com/martanne/vis
Made me doubt about my fidelity towards vis[0] but then realized mle does not have vi-like modal editing.

[0] https://github.com/martanne/vis

It's not general purpose, but colorforth has a really weird and different editor. Coloring words "types" the word (definition label, compiled, immediate, comment, etc), which allows the language and compiler to be dead simple. It really makes me wonder why modern languages aren't designed with IDEs in mind - instead of loading the syntax with complexity, separate it out into the fancy editor layer! Color/text formatting is probably not the best paradigm, but the potential of editor-first language design hasn't really been explored anywhere near as far as it deserves.

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/martanne/vis

Regarding code elegance, OpenBSD[0] surely pride themselves in their code correctness and how they make it clean and understandable.

Another example might be my favorite text editor, vis[1].

[0] https://www.openbsd.org/ [1] https://github.com/martanne/vis

Vis looks like a very minimal but thoroughly modern alternative.

https://github.com/martanne/vis

Emacs and vim are way too complicated to just jump directly to the source code. Try something smaller and more manageable. I would personally recommend vis[1]. Also, take a look at https://texteditors.org/ to discover new editors and resources on design and implementation

[1]https://github.com/martanne/vis

I learned about sam's structural regular expressions after learning about vis[1] on a post in this website. It aims to combine the modal text editing from vi(m) and sam's structural regular expressions, plus some cool stuff like multiple cursors or a Lua API.

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.

[1] https://github.com/martanne/vis

If you like Kak and are vaguely familiar with Sam I suggest trying out vis:

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

Cool project! Reminds me of vis [1] which uses structural regular expressions [2] from plan9 and lua lpeg for the syntax highlighting.

I wonder how these two compare?

[1] https://github.com/martanne/vis [2] http://doc.cat-v.org/bell_labs/structural_regexps/

I've become quite fond of vis[0] and it amazes me how quick it is with gigantic files. It's developed/mantained by a few people so its development is not as quick as one would want, though.

[0] https://github.com/martanne/vis

Speaking of Plan 9 and Vim, readers may also find interesting the Vis editor: https://github.com/martanne/vis
If you're looking for multi-cursor support, you might want to take a look at https://github.com/martanne/vis. It doesn't support ctrl + click, but I find ctrl + n and ctrl + j go a very long way. For anything more complex, vis supports structural regular expressions.[^1] Those work for both replacement (as is customary) and for multi-caret text selection.

[^1]: These structural regular expressions took me a bit to get used to, but by now I really like the concept.

> I guess the big difference is multiple selections. In Kakoune Normal mode you can select multiple selections, and your normal mode commands operate on all those selections at once, and if you switch to insert mode you can insert text at all of those multiple cursors.

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.

I am currently using vis editor[0] and I am liking it.

[0] https://github.com/martanne/vis

Linux vi like text editor using Structural Regular Expressions too https://github.com/martanne/vis
vis comes to mind (https://github.com/martanne/vis), although perhaps something even more aggressively plugin-first would be even better
I've been loving vis¹, a hybrid between traditional vi and sam², a text editor Rob Pike designed from close to scratch.

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

Hey if I may suggest a different editor to you then: https://github.com/martanne/vis It is vi like and combines modal editing with a cool regex command language (based on sam) and multiple selections. I've been using it as my daily driver for about two years now and it's been just great so far.
The idea of programs that work on structured data is quite old. Anyone ever read "structural regular expressions" by Rob Pike? Highly recommended: http://doc.cat-v.org/bell_labs/structural_regexps/

Also, using structural regexps for efficient interactive text editing: https://github.com/martanne/vis

This is SRE in action: 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.

The text editor Vis (https://github.com/martanne/vis, previous discussion: https://news.ycombinator.com/item?id=15710533, https://news.ycombinator.com/item?id=11445389) is explicitly inspired by sam's structural regular expressions.
I've been happily using vis-menu which is a fork of slmenu which is a terminal version of dmenu: http://martanne.github.io/vis/man/vis-menu.1.html

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.

If you're after something lightweight, similar enough to be vim to be useable, and lua built-in checkout vis: https://github.com/martanne/vis

The structural regular expressions are also pretty interesting.

vis is another lightweight but modern alternative to vim these days. I recently switched from vim and sam to vis myself, and recommend it.

https://github.com/martanne/vis

I love to geek out on this sort of stuff. Data Structures for Text Sequences by Charles Crowley [1] is a great read. I would also recommend checking out the Vis editor [2]. It's an interesting Vi like editor that uses the piece chain as its data structure and supports Sam's structural regular expressions.

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

[2] https://github.com/martanne/vis

If you enjoy "redis style" C code, take a look at vis https://github.com/martanne/vis
There's a Lua library called LPeg [1], which introduces a DSL of a kind to Lua that lets you write PEGs with minimal effort. The vis editor [2] uses LPeg files as lexers for syntax highlighting, and they look very clean IMO; for example, this is the C lexer: https://github.com/martanne/vis/blob/master/lua/lexers/ansi_...

[1]: http://www.inf.puc-rio.br/~roberto/lpeg/

[2]: https://github.com/martanne/vis

Thanks for the pointer. I am getting more and more frustrated with Vim (and neovim is not what I am looking for) and looking for alternatives.

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.

https://github.com/martanne/vis

You can be sure that the Kakoune authors are familiar with vi(m).

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

A recent addition is vis[0], which incorporates sam's structural regular expressions.

[0]https://github.com/martanne/vis

That will make a good weekend read thanks! Others may be interested in Data Structures for Text Sequences by Charles Crowley[0] which describes Piece Tables. This is the basis for the Vis editor[1].

[0]https://www.cs.unm.edu/~crowley/papers/sds.pdf

[1]https://github.com/martanne/vis

A number of people expressed the need to edit large files. For the development of my own editor[0] I would be interested to know what kind of usage patterns most often occur. What are the most important operations? Do you search for some (regex) pattern? Do you go to some specific line n? Do you copy/paste large portions of the file around? Do you often edit binary files? If so what types and what kind of changes do you perform?

[0] https://github.com/martanne/vis

I feel the same about 'vis'. Its lightening fast and does what I need.

https://github.com/martanne/vis

I I were going to hack on an C based editor, I think I'd use vis as a starting point:

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

How do you plan to encode binary data in your JSON-based protocol? Base64? This will only increase the overhead.

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.

[1] https://github.com/martanne/vis

This is a wonderful idea! As a compiler person, I'm excited to see how well this works and wish you all the success in the world.

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

[1] https://github.com/martanne/vis

Vim is actually a relatively bad filter (some reasons are mentioned in the caveats section of the article). I explicitly designed my vis editor[1] in such a way that it can be used as an interactive filter. The following works as expected, use :wq to write to stdout:

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

[1] https://github.com/martanne/vis

Well technically you could inline the Javascript+CSS stuff and you would get a single HTML file ;) No need to write anything, it already exists.

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.

[1] https://github.com/martanne/vis

[2] https://github.com/KeyboardFire/mkcast

The article is missing one of the important but commonly overlooked structures: a "piece chain" [1] (aka "piece table"). Not easy to find editors using it, especially among the popular ones, but:

- 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

I'm all for experimenting with new ideas, however this seems to duplicate all the conceptual shortcomings I see in tmux.

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 too find kakoune interesting and have recently begun to add multiple cursor/selection support to my vim like editor.

https://github.com/martanne/vis

I admire Fabrice Bellard. I find amazing the amount of software that he has produced. Some of his creations are remarkable being one-man efforts eg. a compiler, an emacs clone, an emulator, etc.

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.

No. They are not the same and shouldn't be. Rather they should communicate with each other. That is vim shouldn't have its own window functionality but instead detect that it runs within a terminal multiplexer and instruct it to create a new window. When I find the time I will try to experiment with this design in vis.

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.

http://www.brain-dump.org/projects/dvtm/

It actually is on GitHub[0]. I'm not sure why it wasn't mentioned in the mailing list.

[0]: https://github.com/martanne/vis

In my opinion starting out from the mess that vim's code base has become over the years, can't result in something good.

That is why I started from scratch:

https://github.com/martanne/vis