1. 5

    Thank you for this survey, I think kakoune needs more propagation.

    1. 2

      Simplest digramming rules I’ve ever seen, but it seems to be working well.

      1. 1

        Zettelkasten looks like a viable method for working with the notes. I need to research in this direction. Thanks

        1. 4

          Another great post about kakoune. As an old punk myself, I cannot agree more. Even if the connection to Kakoune never came to my mind like this.

          Thanks.

          1. 6

            I really like the concept of Kakoune, tried it a couple of times and inverting the movement to action order is a great UX improvement. But unfortunately my muscle memory in vi is keeping me there, the differences is simply slowing me down too much. I would however love to see someone to “steal” Kakoune style editing in a vim extension, visual mode is the closest we have, which I do use quite a bit but it’s not quite the same.

            1. 7

              I might misunderstand you, but if muscle memory is what’s keeping you in vi, wouldn’t it also keep you from using such an extension?

              1. 1

                The upside is that such an extension could be used on an opt in basis, e.g. by toggling it via a :ToggleKak or as an additional mode which can be entered from normal mode. This would allow me to instantly switch back to normal vi-mode thus making me able to get used to it gradually.

                Additionally I was thinking an extension that keep more original vim movements instead of keeping some and changing others. Word is the same in kak but for instance foregoing g and GG for instance is a massive hassle, I don’t recall on top of my head what more was missing but there was quite a few changes. These changes probably makes sense if you start from a blank slate and thus makes sense for a new editor but as an extension to vi/m I’d rather see adherence to the old learned movement words.

                Edit: Some things that I notice missing/changed at once when starting kak again and just trying to navigate a little bit in the project I’m working on right now:

                • Folding, zc/zo
                • Set line numbers, :set nu
                • Go to line, :n where n is line number
                • gcc/cs are popular plugins for comment and change surrounding, these are popular enough to be ported to vi-mode in other editors like vscode.
                • At this point I’m going back to vi because it’s unfortunately slowing me down to much to get real work done.

                Now I still love what kak is doing and if I weren’t already a vim user a lot of the things probably make a lot more sense.

                1. 5

                  I found that the bindings that got changed from Vim was mostly an improvement in consistency, whereas original Vim bindings are constrained by their legacy. For instance in Kakoune shifted version of keys “extend” your current selection rather than move it. Thus, G is just g (which enters “goto” mode that includes g for buffer begin, j for buffer end etc.) that extends the selection rather than moving it, which is why you need to use gj instead of G to go to the buffer end.

                  Other than folding (which is not currently possible) your other missing features are actually available right now, so if you decide to give it a go again here are some pointers:

                  Set line numbers, :set nu

                  This is available as a highlighter, documented in :doc highlighters and the wiki page

                  Go to line, :n where n is line number

                  This is available with <n>g, from :doc keys

                  gcc/cs are popular plugins for comment and change surrounding, these are popular enough to be ported to vi-mode in other editors like vscode.

                  This is built-in with :comment-line and :comment-block commands, but not mapped to a key by default

                  I can’t blame someone much for not being able to discover some features – while in-editor help with the clippy and reference documentation with :doc is pretty great, it doesn’t have a good “user manual” like Vim that the user can discover features through. The wiki also helps but is not very well organized. TRAMPOLINE is a decent vimtutor replacement, but hard to find unless you know it exists.

                  1. 1

                    Thanks, that’s hugely helpful. Will for sure try out trampoline next time I give it a spin, I do love vimtutor.

              2. 3

                Similarly for me, kak just simply isn’t available as ubiquitously as vi(m). I fear relearning the muscle memory would be a detriment in the long run as I would still likely need to switch back to vi(m) fairly frequently

                1. 2

                  What might be left out about how common place vi(m) is the fact that there are vi(m) modes for A LOT of things, I’m talking editors like VSCode, IDE’s like JetBrains suite, Visual Studio, emacs evil, etc. but most importantly all major browsers (vimari/vimium/vimpinator/pentadactly/qtBrowser/w3m/etc), window managers (ultimate macOS for one), tmux, shells, scripting via s(ed), and more. Wherever these will diverge from kakoune there will be friction in daily usage.

                  Again this isn’t criticism to kakoune just a note on how ubiquitously available the vi(m) keybinding set really is.

                  Additionally to that I’ve worked with industrial control systems often being quite literary air gapped (not uncommonly located in rural places without internet connection) running some flavour of BSD/Linux, vi is pretty much always available for some quick adhoc configuration at a customer site, anything else, not so much.

                  1. 2

                    Yeah, this is also a factor for me, though less so as I have never been happy with a vim plugin/emulation layer.

                    1. 3

                      The one in VSCode is surprisingly good if you bind it to a neovim backend. Onivim is also interseting but more expimental.

                      1. 1

                        Have any sources on the neovim backend? I use neovim as my daily editor and was unimpressed by VSCodes vim plugin about ~1 year ago, but using neovim as a backend might address my concerns.

                        I’ve tried OniVim2, as I purchased a license way back when it was fairly cheap. Their current builds seem very promising.

                  2. 2

                    What distro are you using that doesn’t have a Kakoune package available? About a dozen are supported, it’s surprising to hear that the editor isn’t widely available.

                    1. 5

                      What distro are you using that doesn’t have a Kakoune package available?

                      Telecom-deployed clusters of RHEL VM’s.

                      1. 1

                        Can you not use this RHEL package?

                        1. 1

                          First, no el7 build, second, getting it there would be problematic at best (in terms of file copying).

                      2. 2

                        Alpine Linux. I also occasionally deal with embedded ‘distros’ that don’t have a package manager .

                        1. 4

                          I can see a package for Alpine, I’ve installed it myself in Docker containers.

                          In any case, it’s true that muscle memory is a big obstacle when trying to use one or the other. But when you switch over to Kakoune, it’s harder in my experience to go back to Vi bindings (for example when there’s absolutely nothing else installed on a random system).

                          1. 1

                            When I use vim nowadays (and I install kakoune anywhere I need to edit anything), I am staying only with the very limited set of commads.

                            1. 1

                              The Alpine package is on testing/edge, which isn’t considered stable. I already intentionally stick to stock vi(m) configurations as much as possible to alleviate muscle memory issues, switching seems like a step backwards to me despite the overall UI/UX language being better.

                    1. 11

                      This article is a very nice read. I will be using it as an answer to the many people asking me why kak?

                      I have switched almost a year ago and I cannot imagine myself going back to any other editors I have used before.

                      1. 12

                        And I will steal this paragraph, closest to my heart:

                        If that doesn’t sound anything special, it means that it makes sense. Unfortunately, the field of text editors on UNIX systems has over the years turned into an archipelago, in which every editor aims at being an island. Job management, shell, terminal emulation, window multiplexing… Text editors have turned into closed ecosystems (or Integrated Development Environments) that provide many (sometimes cardboard-looking) features unrelated to editing, which new comers have to buy into, or be left out in the cold.

                        1. 6

                          Then why does Kakoune have a diff algorithm and a json parser among other things? In terms of code, it also uses a few data types/algorithms that standard c++ already provides.

                          1. 11

                            Then why does Kakoune have a diff algorithm and a json parser among other things? In terms of code, it also uses a few data types/algorithms that standard c++ already provides.

                            There’s nothing unusual about the Kakoune project having their own data structures; it’s common for C++ projects to contain functionality that’s also in the standard library.
                            I would say that this reflects more on the language then on the Kakoune project.

                            1. 9

                              There are various places where the internal diff algorithm is used, such as in the terminal output code (on the builtin-terminal-ui branch that replaces ncurses with a custom backend), when we reload a buffer or pipe part of a buffer through an external filter, the diff algorithm allows Kakoune to know what actually changed.

                              Kakoune replaces some of the standard library utilities with its own for various reasons, HashMap is used instead of std::unordered_map to provide slightly different semantics (iteration order matches insertion order for example) and better performance (HashMap uses open addressing), RefPtr is used instead of shared_ptr because we use an intrusive ref count and we share the implementation with SafePtr (a pointer type that makes an object assert at destruction if any pointers to it remain alive).

                              1. 1

                                I think you are mixing two concepts, but I can understand you wrong.

                            2. 6

                              In Dutch, kak is slang for poop / shit. So I find your statement funny, why kak.

                              1. 3

                                Well, it is usual abbreviation of the program. My bad, as it is very similar in Czech (and some other Slavic langs). So better, Why Kakoune?

                              2. 5

                                Thanks!

                                Are you aware of the article (written by the creator of the project himself) titled “Why Kakoune?”, though? I didn’t expect that my article could be seen as an argument for the editor, it’s an interesting angle.

                                1. 1

                                  I was not aware of it, thanks for sharing. Even if it is much more “why”, it is also much longer :-). And programmers love to steal in my experience :-).

                              1. 2

                                Impressive. Smart move.

                                1. 14

                                  The Clojure code example is uncompelling. It would be badly written whether or not it used higher-order functions: first and foremost, the meaningless and abbreviated variable and function names make it hard to reason about.

                                  One side of higher-order functions (either HOF itself or the function that is being passed) should belong to a library. Using HOFs amidst business logic needlessly complicates the code.

                                  I would be more receptive to the argument if you were able to frame this in terms of trade-offs vs. this kind of all-or-nothing perspective. There are plenty of places that higher-order functions can be confusing and hard to understand, but based on the examples and justification presented here I’m unconvinced that I should now take some arbitrary approach of delegating HOFs or their args to libraries, or whatever.

                                  More generally I find this kind of dogmatic thinking in the software industry very frustrating. I feel like it’s prevalent especially in the Clojure community, and is absolutely antithetical to what a programming language community should be–especially one that started off by taking all kinds of inspiration from academic compsci and promoting a culture of curiosity and exploration. This is the opposite of that.

                                  It’s a useful and a powerful tool, but it should be used with restraint and understanding.

                                  I agree! I wish this piece actually explained what that entails.

                                  1. 3

                                    More generally I find this kind of dogmatic thinking in the software industry very frustrating. I feel like it’s prevalent especially in the Clojure community, and is absolutely antithetical to what a programming language community should be–especially one that started off by taking all kinds of inspiration from academic compsci and promoting a culture of curiosity and exploration. This is the opposite of that.

                                    Very well said sir.

                                    1. 1

                                      Well, the tradeoff is obvious: you gain ability to pass strategy down the stack in exchange of simplicity. In my mind it’s a wrong way to do it and usually there are better ways. I guess I’ll need to expand on that.

                                      the meaningless and abbreviated variable and function names make it hard to reason about.

                                      Well, I tried to reduce code to something where it’s small enough to not delve into arguing about it being weird in other ways, I guess that’s what I get in result. :)

                                    1. 6

                                      There is a second article in the series which is even better. Thanks!

                                      1. 4

                                        Yeah, I liked the second one even better: https://carolchen.me/blog/jits-impls/

                                      1. 4

                                        I love this. My main concern is that even a 7.5” e-ink screen would feel like trying to write and read on a postage stamp. When I’m writing I set my font size to be much larger than normal so I can easily skim back over the last few sentences without having to lean in or focus too hard.

                                        I got a Pinebook Pro to ostensibly serve the purpose that this device would serve–a simple no-frills distraction-free writing device. I set it up with Arch Linux and a super minimal windows manager (herbstluftwm) with a few hotkeys defined to open a xterm, open focus-writer, or open a minimal web browser (vimb). I think something like the Pinebook Pro with an e-ink screen would be my dream device.

                                        (Unfortunately just having the ability to drop to a shell is proving to be too much distraction for me, because I’m always wanting to tweak something on the device. Hopefully I’ll get bored of that with so few actual software packages installed and be compelled to spend more time writing and less time tweaking.)

                                        1. 1

                                          You may like this

                                          I was experimenting with a small display attached to raspberry pi zero and displaying only one word at a time. It’s surprisingly pleasant and does not cause eye fatigue. Now I’m experimenting with a tiny board from lilygo t5 with integrated buttons and a lipo battery, should be perfect for short reading sessions.

                                          1. 1

                                            Your last paragraph shows one of the reasons for this, others being battery life and keyboard feel.

                                            For the size, I have not measured it whatsoever, but I guess it will be similar to the visible area on paper arc rising from the real typewriter.

                                          1. 4

                                            I love https://linear.app. It’s very keyboard friendly.

                                            1. 1

                                              That looks awesome, will sign up for their waiting list.

                                              1. 1

                                                Thanks for this suggestion!

                                              1. 12

                                                I’ve come to realize that open source is the only type of software worth investing into. No matter how great a commercial piece of software might be, sooner or later it’s going to either disappear or change in a way that doesn’t suit you. Commercial software has to constantly chase profit for the company to stick around. This necessarily means that the product has to continue evolving to chase what’s currently in vogue. And if a company fails to do that, then it will die and the software will stopped being developed.

                                                This is a bad situation to be in as a user since you have little control over the evolution of a product that you rely on. Instead of the product being adapted to your needs, it’s you who has to adapt to the way the product evolves, or spend the time investing in a different product.

                                                On the other hand, open source has a very different dynamic. Projects can survive with little or no commercial incentive because they’re often developed by the users who themselves benefit from these projects. Projects can also be easily forked and taken in different directions by different groups of users. Even when projects become abandoned, they can be picked up again by new teams.

                                                Evolution of GNOME is a great example of this. There are now many flavors of GNOME all catering to different workflows, and users don’t have to compromise their preferred way of doing things to chase how GNOME is evolving. Meanwhile, users of Windows or MacOS have very little choice but to continue adjusting to the ways Apple and Microsoft choose to evolve the desktop. Microsoft even uses DMCA to prevent users from doing customization.

                                                1. 3

                                                  Speaking as someone who abandoned the Microsoft stack for a much better development experience with free software, it’s worth remembering that free software has its own related failure mode:

                                                  https://www.jwz.org/doc/cadt.html

                                                  1. 3

                                                    I mean, that failure mode is alive and well at the last place we both worked - hardly a problem restricted to OSS.

                                                    1. 3

                                                      Ah that’s subtler - CADPM (Cascade of Attention-Deficit Product Managers) ;-P

                                                      Seriously though yes, it’s certainly not unique to free software.

                                                  2. 2

                                                    I switched to Linux as my main computer at the almost same time as you did (if I recall it correctly) and never looked back.

                                                    I am using musl-linux + wayland on some of my computers which is little unstable combination with proprietary SW (firefox, chromium) and still, it is ten times better than anything I have ever used. Mostly for the reasons Nikita says in this article.

                                                  1. 9

                                                    This article is the most refreshing read about computers since pandemic started. Great Nikita!

                                                    1. 4

                                                      So I went and installed the Syncthing, and the one thing, that struck me is how good it is localized. On top of all the stuff, Nikita wrote.

                                                    1. 3

                                                      You have made significant development. I am sure it will also help the Janet community. Thank you!

                                                      1. 1

                                                        I guess I will move all my FOSS to sr.ht.

                                                        1. 10

                                                          This is indeed a beautiful machine. I am tempted to build it something very similar soon, as I also want to switch to Ryzen.

                                                          1. 2

                                                            Anyone using this? I’d like to know more about your impressions of it. Janet and Joy looks quite neat.

                                                            1. 3

                                                              I am not using Joy (only to steal some ideas), but Janet is the language I have been waiting for my whole life :-).

                                                              Multiparadigm Lisp backed by the C. I even got back to C, to write LevelDB wrapper, and managed to do it after almost 25 without C.

                                                              1. 3

                                                                Thanks a ton for sharing your experiences!

                                                                I just managed to compile Janet on my Windows 10 on ARM64 machine. From the all the test suites, only two tests failed. I’ve just submit an issue to see if I can help debug it. I have zero experience with Janet and my C is quite noob but I’m intrigued by this tiny lisp.

                                                                1. 1

                                                                  I have seen your issue. I hope it could be resolved easily, cause arms are definitelly one of the reason I am interested in Janet.