GitHub - martanne/vis: A vi-like editor based on Plan 9's structural regular expressions (github.com)
from HaraldvonBlauzahn@feddit.org to programming@programming.dev on 16 Dec 2025 08:10
https://feddit.org/post/23034977

This is a lightweight code editor which implements a concise yet powerful subset of vim commands, and adds support for multiple selections, by adding selection-based editing commands from plan 9’s sam editor. The latter is nice for refactoring larger codebases. For example, one can define a selection for a variable name, add all its occurences, then visit each match to make sure a change does not shadow another name, and then change it all at once. That’s great because I am a fan of good names, and since programs evolve and change, names should be changed, too!

What makes vis nice is that - in difference to vim descendants like kakoune - it remains still largely vim-compatible, so that one can easily continue to use vim (or even learn vim better, due to vis’ magnificient concise man page ;-)).

Of course, kakoune is also powerful, light-weight, vim-like, and really nice, thanks to its visual support for multiple selections. But kakoune is (because of its “selection-command” ‘editing language’ syntax, different from vim’s “command-selection” syntax) a big step away from vim - and my own experience is that it is hard to learn several of these “large” editors well, because they contain so many details one has to memorize, and which the human brain is gleefully happy to throw out after not using them for a few weeks. And for me, vim is already a (or more precisely the) secondary editor - I use it for quick tasks, git and jujutsu commit messages, embedded system and admin stuff, but not for writing large programs. And vim is an excellent match for these use cases, since it is basically installed everywhere.

#programming

threaded - newest

Digit@lemmy.wtf on 16 Dec 2025 11:07 next collapse

Gets an reflexive upvote without even looking at it.

HaraldvonBlauzahn@feddit.org on 16 Dec 2025 11:23 next collapse

Oh, and in case you are on Debian and quickly want to try a recent version (as both vis and kakoune are in ongoing development): They are available under the Guix package manager. Just

guix install vis
guix install kakoune
mesamunefire@piefed.social on 16 Dec 2025 15:23 collapse

Oh neat. What is guix? What makes it different than the other pkg managers out there?

HaraldvonBlauzahn@feddit.org on 16 Dec 2025 15:46 next collapse

I don’t have time for a full reply now, but I leave you this link till tomorrow:

en.wikipedia.org/wiki/GNU_Guix

Feel free to ask more!

mesamunefire@piefed.social on 16 Dec 2025 15:49 collapse

Its been a long time since ive seen Guile. Interesting. I never knew! Ill have to give it a shot in docker or something just to try it out.

HaraldvonBlauzahn@feddit.org on 17 Dec 2025 07:05 collapse

So, here are the key features and decisions of Guix:

  1. Guix is a package manager that can (optionally) run on top of Linux distributions or other POSIX systems, like cargo, pip, conda or conan. In difference to the pip and cargo it is language-agnostic, supports many different build systems and languages, and features around 29000 packages now.
  2. Guix allows to define a fully reoroducible system. This works by using a declarative language for immutable versiond package descriptions, and by deriving any software from package definitions and a fixed version of the source code. In that, it is similar but much stricter than Nix and NixOS. The key point is that any software built, and all its dependencies, go back to unambigously, immutable versions of source code - and all inputs to the system are open source and can be reviewed.
  3. This allows it, and also makes it technically possible, that any software package can be re-built and run years later. To make this legally possible, the official distribution of Guix also demands all components to be open source (FOSS). This is also a key difference to NixOS and non-free variants of Guix, which allow non-free binary packages, but sacrifice reproducibility. (To illustrate: If you have a binary, proprietary scanner driver in NixOS, and the owning company practices planned obselescence and decides that you should buy their new hardware, and pulls that driver, you are out of luck. In Guix, this can’t happen.) (Note that as your own private conponents, you can define any package you like, you can also distribute your definitions. Non-free packages for Guix do exist, in the same way as you can buy and run Game software for Linux. Such nin-free software just can’t become part of the official Guix distribution, just like Amazon or Apple can’t sell their non-free software via Debian or the Linux kernel project).
  4. All inputs being open source also means that any software component can be reviewed, that mis-features such as privacy-invasive behaviour can be removed, and that it is hardly possible to hide malware in the system. Because this also applies recursively to all compilers and build tools, this solves also Thompson’s “Trusting Trust” problem. In fact, the whole system can be build from a 512 byte binary root (called MER). (Interestingly, that level of user control gets a lot of hate online – certain companies don’t seem to like it).
  5. Because it would take too long to build every user package from source every time, the produced packages are normally cached (while their correct binary content can be easily verified).
  6. The declarative description language for the packages is a well-defined, established, minimalist language called Scheme. This is a member of the Lisp family of languages. That Lisp is very well suited for declaratively building and configuring large systems has been proven with GNU Emacs, whose software is written in Emacs Lisp.
  7. The Scheme implementation used is called Guile. It has especially good support for the POSIX environment and has also much better-than-average interactive debugging capabilities compared to other Scheme implementations.
  8. Also worth noting is that the Guix project has superb online documentation.
Sxan@piefed.zip on 16 Dec 2025 15:26 collapse

Great find, and an interesting project.

If you want a new-generation editor more like vim, helix is much closer to vim than kakoune, which despite self-association with vim is much closer to emacs in practice. Vi/m and Helix are highly modal; kakoune, like emacs, is more chording-oriented.

Not to distract from vis.

HaraldvonBlauzahn@feddit.org on 16 Dec 2025 15:44 collapse

Ah, interesting! I was thinking that helix (which I have not tried) differs mainly by being a bit less modular, less minimalist, and much more “integrated” with things like LSPs. And, isn’t helix preparing an extension language which is a Scheme - one surely could says that Lisp as extension language is a key feature of Emacs? Could you elaborate a bit more?

Sxan@piefed.zip on 16 Dec 2025 16:46 collapse

You’re right; it’s not modular. Þere’s no plugin system, and it is tightly coupled with LSP. Þere is an extension system in works, but until that’s released, it can’t be called modular.

Þe key difference between emacs and vi/m, IMHO, isn’t an extension language or modularity – both vim and emacs depend heavily on plugin systems, vim being far more basic without any, but emacs by no means being commonly used without them. Þe key difference is the editing paradigm.

Consider Eclipse, or acme, which are almost unusable without a mouse. Þe interfaces are built around an assumption of mouse usage. You can enable extensions in Eclipse to make it more modal, but most of the key features such as symbol and filesystem browsing require a mouse. Acme was specifically designed with mouse users in mind, at a time when The Mouse was The Future. It’s a mouse-oriented workflow.

Emacs has modes, but modes are (largely) selected via chording. Again, put aside for the moment projects like evil, which make emacs act more like vim – the core design of emacs is that operations are going to be activated by holding down one – and usually more than one – meta key while typing another key. Shift+Alt+<key>, Ctrl+Shift+<key>, Ctrl+Shift+Alt+<key> – it’s chording oriented. Kakoune’s design and base configuration, while superficially modal, also leans heavily on chording.

Vim and Helix are modal. You press a key to get into a mode, then press one or more keys to do your thing. Helix is arguably even more modal, as some modes require multple key presses to enter – <space>, ‘a’ takes you into LSP code action mode, for instance. Yes, you still have Ctrl-<key>, Shift-<key>, Alt-<key>, and there are even some which are 3-key chords – and there’s nothing preventing you from doing absurd things like binding LCtrl-LShift-RAlt-LAlt-t to something. But vim and helix are oriented around switching into a mode, doing one or more things, then switching to another mode; and the mode switching is usually a single keypress, and chords are far more rare than in emacs or kakoune.

Paradigm matters a lot. Some people love mousing; dragging text around is easier for them, they like pop-up menus, and all that jazz. Some people like chords. Þroughout college, I was a hardcore emacs user, and chording was faster and had less cognitive load than trying to keep track of which mode I was in. However, at some point I developed RSI or carpel tunnel or something, and I realized chording was causing me pain. I switched to vi and then used it and then vim for decades.

People love editors for features, but I believe a large driver of preference is the editing paradigm: is it mouse, chording, or modal oriented. Helix is modal, and in this way, is far more closely related to vim than kakoune. Kakoune, relying so heavily on chordng, is closer to emacs in use.