Kakoune
,I’m not writing this post in vim, which is really a rather odd concept for me. I’ve written quite a bit about vim in the past; it has been my most faithful writing companion for many years now. Part of the reason is its portability and POSIX inclusion – it (or its predecessor, vi) is likely already on a given system I’m using, and if it isn’t, I can get it there easily enough. But just as important is the fact that it’s a modal editor, where text manipulation is handled via its own grammar and not a collection of finger-twisting chords. There aren’t really many other modal editors out there, likely because of that first point – if you’re going to put the effort into learning such a thing, you may as well learn the one that’s on every system (and the one with thousands of user-created scripts, and the one where essentially any question imaginable is just a Google away…). So, I was a bit surprised when I learned about Kakoune, a modal editor that simply isn’t vim1.
Now, I’ve actually written a couple of recent posts in Kakoune so that I could get a decent feel for it, but I have no intention of leaving vim. I don’t know that I would recommend people learn it over vim, for the reasons mentioned in the previous paragraph. Though if those things were inconsequential to a potential user, Kakoune has some very interesting design ideas that I think would be more approachable to a new user. Heck, it even has a Clippy:
~ ╭──╮ ╭───┤nop├────╮
~ │ │ │ do nothing │
~ @ @ ╭╰────────────╯
~ ││ ││ │
~ ││ ││ ╯
~ │╰─╯│
~ ╰───╯
nop unset-option █
:nop content/post/2018-06/kakoune.md 17:1 [+] prompt - client0@[2968]
Here are a few of my takeaways:
- There’s no inbuilt window management/splitting, by design, which is something that I understand but do not like. The idea is that different sessions running in different X windows or tmux splits can communicate with each other, so the windowing burden is better left to these systems. This is fine, I guess, on my Linux box with i3. Less great on my Cygwin or Darwin terminals where I don’t particularly want to run a multiplexer just for a text editor. While I often have multiple splits open in vim to bounce content around, I do the rest of my multitasking via simple job control. Lack of windowing also makes it unsuitable for diffing.
- There’s no inbuilt file browser, which is also by design. This is technically true of vim also,
netrw
is a plugin, but it’s there by default.netrw
is much-maligned, but when necessary I do like to be able to:e .
and find my way around. - Kakoune takes a very long time to start up (well, for a text editor), which is odd since the previous two design decisions are listed alongside the editor’s goal of being snappy.
- There’s no inbuilt spellcheck, which makes sense if you’re only targeting coders. But only targeting coders is kind of a dumb choice when minimalist editors are great for distraction-free prose writing, and formats like Markdown, Textile, and Fountain make WYSIWYG a regrettable memory.
- Normal mode is always a selection mode, essentially akin to Visual mode in vim. This is a real standout feature that both cleans up the number of modes (compared to vim), and simplifies the language and consequences of an action. In vim, I can make a guess at how many words I need to delete, aiming to under- instead of over-shoot, and end up doing something like
10dw 2dw
, or I can step into Visual mode. In Kakoune,10w
automatically selects those ten words, and then2W
adds two more to the selection. I guess this seems trivial, but in practice I feel a lot more grounded as far as knowing what text I’m operating on. And this is after years of using vim. Moving around as normal (with hjkl) is still a selection, it’s just a selection of one character. - The cursor doesn’t change when you switch between normal and insert modes, which may or may not be related to the previous point. Some people seem to think it is, but I don’t think anyone on the dev team has said as much, and it honestly makes no sense – the cursor being a block in normal mode suggests that operations happen on characters in normal mode; being a bar in insert mode suggests that you can’t be on a character, only before or after one. Anyway, I had no idea how much I relied on that until I kept getting mode-lost. Apparently it isn’t being fixed any time soon.
- Fortunately, changing the status bar’s color based on mode was not terribly tricky, handled via something Kakoune calls hooks, very similar to autocmds in vim. More awkward, in my opinion – every hook needs a filename regex, so in the case of changing part of the colorscheme based on mode, you have to drop in a pointless
.*
. At least the format of these commands is always the same, there’s no contextual change. It should also be just as easy to change the cursor color, partially mitigating the previous issue. - In general, configurations are awkward just like the previous point. Much of this is justifiable – for instance, word-wrapping and line numbers aren’t normal options, they’re baked into ‘highlighters,’ which feels super weird coming from vim, but might make sense for some users who, say, want line numbers for code but not prose. I prefer consistency, and even wig out a bit when vim’s help behaves differently than my other files.
- Despite the awkwardness, making a colorscheme was fairly straightforward, which is good because defaults are kind of bonkers, and the default colors were not terribly serviceable. On the topic of defaults, I have yet to get Markdown highlighting to work. Everything is just a little bit fidgety. I’m going to play with it a bit more, but will probably post decolletage.kak at some point.
- Keybindings rely heavily on Alt instead of Ctrl, which… might be justifiable, because in a standard keyboard configuration, Alt is less awkward to chord than Ctrl. But it goes against all terminal standards, and people have ways of making Ctrl work (*cough* reassign Caps Lock *cough*). If the dev team wants any vim converts, replacing things like Ctrlo with Alt; is just a weird move.
- Documentation is severely lacking in comparison with vim, but there is one area that’s considerably better. Remember Clippy up there? There is a ton of inline help and guidance, which works great when you sort of know what you’re doing, but isn’t as helpful as far as discoverability.
- Multiple cursors are built in, and alongside the normal-is-always-selection-mode paradigm, it works really well. For a while I used vim-multiple-cursors, which is pretty impressive, but kind of felt like a crutch or a bad habit more than anything else. There was nearly always a native vim way to do what I was trying to accomplish. Kakoune’s multiple cursor system is a native solution, and much like the selection model, actually feels like its helping and guiding you.
I guess there are far more negative points in that list than positives, but the truth is that the positives are really positive. Kakoune has done an incredible job of changing vim paradigms in ways that actually make a lot of sense. It’s a more modern, accessible, streamlined approach to modal editing. Streamlining even justifies several of my complaints – certainly the lack of a file browser, and probably the lack of splitting fall squarely under the Unix philosophy of Do One Thing and Do It Well. I’m going to continue to try to grok Kakoune a bit better, because even in my vim-centric world, I can envision situations where the more direct (yet still modal) interaction model of Kakoune would be incredibly beneficial to my efficiency.
netrw and invalid certificates
,Sometimes I just need to reference the source of an HTML or CSS file online without writing to it. If I need to do this while I’m editing something else in vim
, my best course of action is to open a split in vim
and do it there. Even if I’m not working on said thing in vim
, that is the way that I’m most comfortable moving around in documents, so there’s still a good chance I want to open my source file there.
netrw
, the default1 file explorer for vim
, handles HTTP and HTTPS. By default, it does this using whichever of the following it finds first: elinks
, links
, curl
, wget
, or fetch
. At work, we’re going through an HTTPS transition, and at least for the time being, the certificates are… not quite right. Not sure what the discrepancy is (it’s not my problem), but strict clients are wary. This includes curl
and wget
. When I went to view files via HTTPS in vim
, I was presented with errors. This obviously wasn’t vim
’s fault, but it took a bit of doing to figure out exactly how these elements interacted and how to modify the behavior of what is (at least originally) perceived as netrw
.
When netrw
opens up a remote connection, it essentially just opens up a temporary file, and runs a command that uses that temporary file as input or output depending on whether the command is a read or write operation. As previously mentioned, netrw
looks for elinks
, links
, curl
, wget
, and fetch
. My cygwin install has curl
and wget
, but none of the others. It also has lynx
, which I’ll briefly discuss at the end. I don’t know if elinks
or links
can be set to ignore certificate issues, but I don’t believe so. curl
and wget
can, however.
We set this up in vim
by modifying netrw_HTTP_cmd
, keeping in mind that netrw
is going to spit out a temporary file name to read in. So we can’t output to STDOUT, we need to end with a file destination. For curl
, we can very simply use :let g:netrw_HTTP_cmd="curl -k"
. For wget
, we need to specify output, tell it not to verify certs, and otherwise run quietly: :let g:netrw_HTTP_cmd="wget --no-check-certificate -q -O"
.
I don’t have an environment handy with links
or elinks
, but glancing over the manpages leads me to believe this isn’t an option with either. It isn’t with lynx
either, but in playing with it, I still think this is useful: for a system with lynx
but not any of the default HTTP(s) handlers, netrw
can use lynx
via :let g:netrw_HTTP_cmd="lynx -source >"
. Also interesting is that lynx
(and presumably links
and elinks
via different flags) can be used to pull parsed content into vim
: :let g:netrw_HTTP_cmd="lynx -dump >"
.
ep
,I spend a good deal of time inside a terminal. Text-based apps are powerful, when you know what you're doing, and fast (also when you know what you're doing, I suppose). If an equivalent Cocoa or X11 GUI tool offers me little advantage, I'm probably going to stick to either a CLI- or TUI-based piece of software. One of the more important, taken-for-granted pieces of the command line environment is that of the pager. Typically, one would use something like more or less for their pager. For a while, I used w3m as my pager, as well as my text-based web browser. Then Snow Leopard came out, and everything from MacPorts got totally jacked up and left much of my system jacked up as well. Parts of it I've fixed, other parts I've been lazy about. For that reason, or perhaps not, I have transitioned to ELinks as my text-based web browser. Today, after recent discussions with a friend regarding w3m and ELinks, I had a thought - why not use ELinks as my pager as well?