What does HackerNews think of vis?

> 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

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

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/

Speaking of Plan 9 and Vim, readers may also find interesting the Vis editor: https://github.com/martanne/vis

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

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/

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.

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.

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

This reminds me of "vis" from about a year ago - https://github.com/martanne/vis

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

[0]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

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

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