I would love for people to steal Kakoune's text editor, I think it's an improvement over Vim for modal editing.
I've been a longtime user of the Vim style of editing, but I checked out Kakoune several years ago and was impressed. I tried it for a week or two and was starting to prefer it over Vim.
The problem is that while Kakoune is a very good competitor to Vim the program, I am only rarely in need of a terminal based editor. The vast majority of my time is spent in full fledged IDEs or in Web-based editors, all of whom have Vim plugins so that I can consistently use the same style.
It's always bummed me out a little bit. I spend the majority of my work days using Vim keys for editing text, and there is an editing style I'd actually prefer to use but I can't because there isn't already widespread adoption. There's not enough benefit for me to learn it if I can't use it everywhere, and switching back and forth with Vim seems extremely difficult.
I really regret every trying Kakoune. It was totally not worth it, but I just can't go back now.
I've switched from Vim to Kakoune 3 years ago, and lack of support for this modal editing style elsewhere is really frustrating. It is better than Vim's, but in practice that's not a significant difference, and the pain of switching back and forth is something I'm agonizing over all the time.
BTW. The exact kakoune modal editing mode is not even all that flawless. The way x and X work on empty lines is infuriating, and I am actually using a personal fork of kakoune to fix it. https://github.com/dpc/kakoune-dpc . I went so far as prototyping a spinoff of Kakoune: https://github.com/dpc/breeze to look for improvement, but building a full-featured text editor is a lot of work, and I it's not like it's going to fix the problem of switching.
>Would you say a few words on what makes Kakoune modal editing better than Vim's?
I guess the big difference is multiple selections. In Kakoune Normal mode you can select multiple selections, and your normal mode commands operate on all those selections at once, and if you switch to insert mode you can insert text at all of those multiple cursors.
I had a paragraph with examples that I just deleted because it had sentences like "you would simply type s;<enter>b&" and that makes you sound like a crazy cultist. A better endorsement is maybe: where I would in the past write a script in python or awk to get info from a log or a csv I usually just jump straight to kakoune and edit the file down to the data I want.
There is a multiple cursors plugin for vim that I use; it's a bit clunky at times, but it does the job. How is kakoune's multiple cursors support better than that? How cool is it, so to speak?
Btw the reason I haven't tried kakoune yet is that the command is `kak`, which means 'shit' in my native language, Dutch.
>There is a multiple cursors plugin for vim that I use; it's a bit clunky at times, but it does the job. How is kakoune's multiple cursors support better than that? How cool is it, so to speak?
I haven't used the vim plugin but if vim commands work on each selection that probably gets you half way. Kakoune additionally provides 's' and 'S' commands to sub select down from your selection iteratively. you might select all words, then select the _ in each word, delete the character and hit ~ to capitalize the next character to convert a selection of words in snake_case to camelCase. I think it's cool.
>Btw the reason I haven't tried kakoune yet is that the command is `kak`, which means 'shit' in my native language, Dutch.
I've actually heard this either on a forum, mailing list or a github issue at least once, lol. It's unfortunate.
>> Btw the reason I haven't tried kakoune yet is that the command is `kak`, which means 'shit' in my native language, Dutch.
> I've actually heard this either on a forum, mailing list or a github issue at least once, lol. It's unfortunate.
I think if someone really wants to use Kakoune they could do the same thing that I do with neovim, which is to make vim be an alias for the editor you actually want to use.
Speaking of unfortunate naming: 'bash' is pronounced exactly like the Norwegian word 'bæsj', which also means shit/poop. This has been the cause of some hilarious situations where non-technical people have overheard a nerdy conversation
> I guess the big difference is multiple selections. In Kakoune Normal mode you can select multiple selections, and your normal mode commands operate on all those selections at once, and if you switch to insert mode you can insert text at all of those multiple cursors.
This is why I switched to vis (https://github.com/martanne/vis) after trying kak for a couple days (and previously being an nvim user). ^k and ^j add cursors directly above and below the current one, :x/foo/ selects all occurrences of ‘foo’ in the current selection or (if there’s no current selection) file (this is based on the command language of Rob Pike’s `sam` editor, and foo can be a structural regex), and then you can manipulate them using standard vi bindings.
And I consider multiple selections a flaw, a poor man's search&replace. Particularly with neovim's
set inccommand=split
(live substitution). Vim's confirmation prompts make it more comfortable, as well as off-screen matches it shows. Multiple selections are inherently limited to a single screen or you won't be able to see what you're doing.
Kakoune goes the opposite way, there is no such thing as "search and replace" in it, you'd use multiselection for that.
It ends up being much more powerful because the editing language is strictly more expressive than regular expressions: you can select using a regular expression, but you can also use all the rest of the normal mode, such as select/jump to the matching parenthesis or brace (or whatever pair of text your language use to scope things), which is not possible to express in pure regex.
You are far from limited to a single screen, the `(` and `)` commands rotate the main selection, so you can inspect all your selections easily if you want to.
In my experience (as a long time Vim user and as Kakoune's main author) multiple selections end-up being much more attractive for quick edits where there's only a handful instances to replace than devising the correct regex/replacement pair, and their interactive nature makes them quicker to use than the macro alternative (which is also supported in Kakoune).
I'd just like to add that if you want to do regex-based search and replace like in Vim, it's super easy to pipe your selection through sed. The way Kakoune implements pipes is just amazingly good. I love that if you have multiple selections, each one gets piped through the command. I love that you can undo piping your selections to another program. And while I've barely scratched the surface of what you can do with macros, I have a couple that I use constantly. After 19 years with vi and then vim, I switched to kak after trying it for a week.
In summary: great job with Kakoune! I'm a delighted user.
As I've said in a thread I made on forums a while ago, search&replace has other advantages. Reviewing matches, as long as you use /gc, is the default in vim. It's opt-in in kak, which I think is a bad default. Does kakoune even indicate you have some other selections off-screen?
I worked with large and messy codebase, where apparently there was always something more important than cleaning up.
I considered multiple selections a bit of a gimmick in sublime text and various emacs/vim extensions but the way it works in kakoune feels completely different.
Think about vim (and kakoune) as basically a highly interactive language for editing text. At least at a conceptual level something like diw is basically a function (d) applied to data (iw). Vim is completely scalar. The type of all the functions is more or less something like string → string. Kakoune is the APL of text editors. Multiple selections are an array of strings to operate on. It automatically maps the function (editor commands) over every selection. I find this extremely attractive and powerful.
At least for me kakoune blows all other editors out of the water. It really is quite good.
When I tried `set inccommand=split` in neovim it would sometimes freeze the editor, even when substituting regular-sized files (several Kb), so I had to deactivate it. Granted that this was some time ago, so it might have been improved with recent versions.
To me however multiple selections are not Kakoune's strongest point. It's the fact that in Kakoune you "first select, then modify", while in vim you go "action first, then subject".
Putting the subject first allows for a more visual experience in general - in Kakoune you can always "see what's going to happen" before it happens, because the object is always highlighted. The multiple cursors thing is just a manifestation of this approach. In Vim the experience is more "opaque" - you type some commands in normal mode and suddenly the text changes. As a result Kak is less prone to "accidental edits" like I get in Vim from time to time.
I've heard that some people "abuse" on Vim's Visual mode to get over this limitation. But that feels like a kludge to me. And it doesn't solve the accidental edits.
Multi-cursor is actually a better version of search-and-play-macro, not search-and-replace.
The advantage of it is that you can execute the "macro" incrementally and spot early when you've made a mistake, rather than recording a macro then letting rip and discovering, too late, that there was a mistake 80% of the way though, and now you need to undo the whole thing and and try again.
(I use multiple-cursors in Emacs for multiple selections, iedit-mode for live substitution (sometimes in combination with wgrep), as well replace-regexp for plain search & replace, and while they all overlap, none are poor versions of any of the others. They each have their strengths and weaknesses. However it's vanishingly rare that I use macros any more.)
I think more than anything, you've convinced me that I'm probably never switching to Vim. I've really considered it because a lot of people I've worked with use it and claim it makes them much more productive, but I've been pretty productive in my IDE and I've been doing all those multiple selection and "scripting" type things in Sublime and IntelliJ for years.
Before 3 yeas of kakoune, I did like 20 years of Vim. IMO, typing is less than 0.1% of SWE, so even if you can get 2x typing productivity with Vim it will still not amount to any substantial overall productivity benefit.
If IDE works for you and you enjoy it, stick with it. I enjoy modal editing (Vim/kak) because it feels good. I don't have to move my hands from the home row and I'm a damn impatient person, so that fast editing just makes me feel a little better about "waiting for IO".
Editing in Vim feels like a bit like editing in `ed` if you ever tried it. It's a bit like "type in a command, and see the result". You type d3w and you will get 3 word deleted. In Kakoune every keypress results in visual response. You type 3w, you see that 3 words were selected, then you hit d and they get deleted. It makes editing much more interactive, smooth and less error prone.
Unlike the other responder, I am actually not big fan of multiple selections and prefer search and replace. But once in a while multiple selections come handy even for me, so I don't mind them being there.
If it's so painful for you, maybe try dropping the IDEs and web editors? To be clear I know that there's nothing wrong with liking IDEs, I'm not that much of a purist, but there's also nothing wrong with not using them. Over the past decade I've worked with all kinds of technologies, from the web to bootloaders, from Perl to Rust and I've done it all without using any IDE.
Again, I'm not advocating against IDEs out of principle, it's just that if your current setup is so frustrating for you at the moment I really think you should consider something a bit radical to improve it. When something in my code workflow feels "sticky" I always find that it's worth taking the time to find a solution, after all we spend so much time using these tools...
I personalty use both types. IDEs have their place. So do the 'minimal' editors. The biggest gripe I have with modal editors like vim is they seem to adhere to the path of most surprise instead of least. With most IDEs they try to get you into moving text into a file quickly. A modal editor you first have to learn how to just change modes. I can not number the amount of times I started typing and had the conclusion 'I have no idea what I just did to my document and what state the editor is in now'. Which is maximum surprise :) I get why they were made in the first place. They are a thing of teletype machines. Yet we keep this mode style editor around. It is interesting. I personally am kind of stuck with this right now due to the way my work manages machines. So I am stuck with whatever the box has on it. So minimal customization is allowed.
There's definitely a steeper learning curve to modal editor, that's for sure. And vim is pretty bad at communicating what state it's on, especially with the default config.
But my point is not so much about modality (I used emacs for a very long time before switching to vim) it's more that the parent seems to really like this kakoune editor, so why wouldn't he just use it full time instead of switching constantly?
> I spend the majority of my work days using Vim keys for editing text, and there is an editing style I'd actually prefer to use but I can't because there isn't already widespread adoption.
Unless your preferred style has some really unusual key combos, it seems to me that most IDEs and editors today enable you to configure your keys just the way you want them.
You might not realize that when it comes to vi keys, or I assume (per context) Kakoune -- it's the ability to compose commands out of smaller bits. If the editor doesn't support the appropriate composition elements, you can't get there with simple key-remappings, for even if you (vi-wise) tell it 'dd' deletes a line, that won't get you 'd$' for delete-to-end of line, 'df)' for delete-to-next-parenthesis, etc.
Sadly, because I'm someone who learned vi in part because it's nearly everywhere and fits on the embedded devices I often develop for easily, a new editor isn't as interesting because it isn't everywhere.
Applications that are not integrated into Emacs sometimes implement 'vim keys' for interface. If you get used to kakoune keys, you may struggle each time you use them.
I’m being triggered by the use of Unlicense, a license that I abhor purely because of its catastrophically bad name.
The problem is that when expressed in the past tense (-ed suffix), “Unlicense” means precisely the opposite of an existing English word.
If software is unlicensed, it means you have no license, no permission, to do anything with it. (Or, if it is your code, it means that you have not granted license/permission to anyone else to do anything with it.)
If software is Unlicensed, it means you have permission to do absolutely anything with it.
That’s a recipe for confusion.
In old versions of npm, to convey “all rights reserved” or “proprietary” you used to need to set the license field in package.json to "UNLICENSED"; so that "UNLICENSED" was the opposite of "Unlicense" (and I think it was case-insensitive, too).
And just so we’re clear, it’s not the word “unlicensed” that’s at fault, it’s Unlicense that’s at fault for hijacking an existing word to mean the opposite thing. Which is hardly a new phenomenon in language, I suppose (let, cleave, sanction, &c.), but still—.
When I want public domain and want to be nice about the legal technicalities for all jurisdictions, I use CC0 instead, largely just because its name isn’t bad, but also because its contents seem to be slightly more highly regarded legally. https://creativecommons.org/choose/zero/
In this case something different but related is going on: software engineers have come to perceive a license as something negative, as something that sets limitations on what you can do. This makes an un-license seem desirable, as it's freedom from restriction. This also matches our behavior: code on a blog post is assumed to be free to copy and use, unless it has a license attached that limits this freedom.
In reality of course the base state is reversed: having no license means you are allowed approximately nothing, and a license gives you (often limited) rights to do something with it. In reality an un-license would take away rights you previously have been granted.
It feels like we are on the threshold to license becoming a Janus word.
> The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.
This highlights an interesting philosophical disparity. You (correctly) point out that a license is a "permission to do something" - but the perception among folks appears to be that the license is in fact what restricts your permissions. Thus, from their perspective, "the smaller the license, the larger your freedoms" - and, so, they conclude (incorrectly, but understandably) that the end-point of "no license whatsoever" would correspond with "complete freedom".
And if you want something OSI-approved you can use either the MIT-0 [1] or the Zero-Clause BSD [2] license. The MIT-0 license is the MIT license without the attribution requirement, the Zero-Clause BSD license is (somewhat misleadingly) the ISC license without the attribution requirement.
I’ve heard that CC0 is better for content than code (though I can’t remember exactly why). Either way, I wish the Unlicense and WTFPL people would get over themselves and just go with MIT: a license that I think they would use if it was called the “Do-What-You-Want-Just-Don’t-Sue-Me” License.
Creative Commons generally is better for content than for code. CC0 is an exception. It tries to put something into public domain and where that is not possible tries to grant the same rights.
Thanks for the correction. I’ve even confused myself on this one because of the title of https://github.com/npm/npm/issues/8918 before, and I did it again now a few years later! My apologies.
One shouldn't really care what npm did/does outside npm projects unless that aspect of npm becomes widespread beyond their eco-system. And it seems the Unlicense predates npm by at least 11 days (1 January 2010 vs 12 January 2010, but it seems like npm didn't start that word for this meaning until much later anyway).
I wonder how much the Unlicense's name was inspired by 7-Up's long-running "The Uncola" advertising campaign or other similar pop culture usages of "un-" as a joke-ish like that.
It's not a perfect use of the word, perhaps, but it's cute without being offensive so I like it (this is ignoring any actual concerns about its content, which would be a distinct discussion).
If you miss out on Kakoune because you don't like the name of the license, that's a shame. It's really good. Neither am I a huge fan of Unlicense, nor do I think C++ is all that great, but Kakoune is nevertheless excellent.
The right to the copy/text? The right to being allowed to reproduce? The copyright holder is the person who has the right to do so. Seems ok to me.
In any case, it’s a well established old term now while Unlicense was coined long after unlicensed was already an established word with a different (opposite!) meaning.
Edgecases like this is probably why they include the "Unlicencse" license. Afaik, while (edit: In Germany) you cannot actively void your rights on a project (i.e., what they call the public domain model here) you can license it similarly (e.g., via CC0 and possibly the "Unlicense").
CC0 is much more thorough than the Unlicense, was written by actual lawyers, and has a fallback to a maximally-permissive license in jurisdictions where willing relinquishment of copyrights into the public domain doesn't exist. Unlicense doesn't have any of these properties so it really should be strongly avoided when choosing a license for a project -- there's no benefit to using it over CC0 and several potential (though admittedly theoretical) downsides.
The Unlicense website also incorrectly states that "CC0 is not intended for software" -- while the other CC licensed aren't good choices for software, CC0 most definitely is intended to be used for software as much as any other copyrightable work.
In Germany a work can only enter the public domain after the copyright expires. The author is not allowed to waive their copyright and intentionally put their work in the public domain before that. If you want to make something available without restrictions you have to grant people a license to your copyrighted work.
One of the things that is different is the matter of Moral Rights such as the right to be attributed as the author of the copyrighted work. In some jurisdictions those rights cannot be waived. https://en.wikipedia.org/wiki/Moral_rights
But to me the similar construction in French would be "cacaounet" and not "cacounet" which doesn't really evoke feces to me, just "a small cacou" whatever that'd mean.
what i'm sorely missing from this otherwise very good post is some screenshots! i've only heard about kakoune in passing and i'm intrigued by clippy and its dependency info popup feature, but it'd greatly help to actually see it.
Really cool editor.
I was looking for editors that could run in terminal and I came across kakoune and what I really liked about this editor was auto suggestion feature and clippy look a like that tells you which command does what.
Really? I never would have guessed. It’s probably different for other accents, but with an Australian accent a word spelled like that would never be pronounced like “cocoon”.
That's surprising, since I'd expect Australian accents to pronounce the first "o" as a schwa (think the second "o" in "doctor"), which is in a way similar to the French "a".
You feel this limitation because Alt key is overloaded in Kakoune. Which in my opinion is a downside of having less modes than Vim. Only normal and insert. When you look at kakoune forums, there's constant head scratching where to put new potential functions or user macros. Default keymap is so crowded.
IMHO we are trained to look for a home link in the header.
I'd say that, even though the author put a link in the article, it's easy to miss it if you read the whole article first, then try to find more informations about Kakoune :/
May be you're looking at a wrong place? It's just a simple <a> tag, it should work. I can see link at first word in the sentence "Kakoune is a (fairly) young modal code editor that has matured for as long and as well as a good red wine."
Probably not what's happening here. But even "simple a tags" regularly break on iOS, because Safari has heuristics to see if the hover effect is to show something (like a menu), so then the first click triggers the hover, and the next click the actual click. Really frustrating as the heuristic is often way off.
I've been a longtime user of the Vim style of editing, but I checked out Kakoune several years ago and was impressed. I tried it for a week or two and was starting to prefer it over Vim.
The problem is that while Kakoune is a very good competitor to Vim the program, I am only rarely in need of a terminal based editor. The vast majority of my time is spent in full fledged IDEs or in Web-based editors, all of whom have Vim plugins so that I can consistently use the same style.
It's always bummed me out a little bit. I spend the majority of my work days using Vim keys for editing text, and there is an editing style I'd actually prefer to use but I can't because there isn't already widespread adoption. There's not enough benefit for me to learn it if I can't use it everywhere, and switching back and forth with Vim seems extremely difficult.