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

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.

  • HaraldvonBlauzahn@feddit.orgOP
    1·
    13 days ago

    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.