25 ms·

Why Kakoune – The quest for a better code editor

631 points by petepete 10y ago

aamederen 10y ago
I liked the ideas and especially the paperclip :) I couldn't find whether it is completely written from scratch or a vim fork? If not, why is it not a vim fork?
- petepete 10y ago
  I believe it's a complete re-implementation. I think with so many 'deep' changes to the functionality, rewriting would probably be easier than forking.
- pietrofmaggi 10y ago
  From the github repository: https://github.com/mawww/kakoune https://github.com/mawww/kakoune reply Vim inspired — Faster as in less keystrokes — Multiple selections — Orthogonal design
- omtose 10y ago
  You can also use a cat or nothing as "helper".
- rz2k 10y ago
  The code statistics on github[1] show almost all C++, while vim is written in C. According to the author the project began as a reimplementation or merely a rewrite of vim then turned into a more ambitious reimagining of how to design a modal editor. [1] https://github.com/mawww/kakoune https://github.com/mawww/kakoune
- doppioandante 10y ago
  It is written from scratch in a very modern C++ style, I advise every C++ programmer to look at it. Also the code is quite well organized.
diggan 10y ago
Might be a good idea to include a link to this new editor at least somewhere in the text. I couldn't find even one little link...
- pietrofmaggi 10y ago
  You can find the editor source, and installation instructions on github: https://github.com/mawww/kakoune https://github.com/mawww/kakoune
  - diggan 10y ago
    Thanks! However, my point was that people shouldn't have to read comments on HN to be able to find the editor (I thank you for helping me though!) that someone wrote a whole blogpost about.
    - notheguyouthink 10y ago
      I agree with you, though it's a frequent issue that blog posts don't link back to the main site. With that said, it's fairly obvious to go to the root domain for something like a blog post, and that's how i found it. Definitely should include a link, though.
nerdponx 10y ago
Looks great. Does it have a different scripting language, or is it still VimL? What kind of plugin support does it have? Is it embeddable? Does it have a messaging API like Neovim? How well does it handle long text lines and long documents?
- omtose 10y ago
  Some answers as a user: No scripting language, most of the heavy lifting done in plugin is through shell calls (asynchronously or not). Example here [1]. I personally think that it's kinda hard to grok to be honest. Thanks to the client server architecture, it is possible to make an external UI[2]. There is no line wrapping currently. Don't know about long documents, but the editor in general is very efficient. [1] https://github.com/mawww/kakoune/blob/master/rc/core/grep.kak https://github.com/mawww/kakoune/blob/master/rc/core/grep.ka... [2] https://github.com/mawww/kakoune/blob/master/doc/json_ui.asciidoc https://github.com/mawww/kakoune/blob/master/doc/json_ui.asc...
  - notheguyouthink 10y ago
    What is your 1st example exactly? I mean, if Kak doesn't come with a scripting language, then what language is that exactly? This is an important note to me, because i imagine i'll have to implement my own tools for common language tasks like Gofmt and Goimport. Honestly, it would be cool if i could write plugins in any language i want, ie if it fully uses a backend editor server API.
    - omtose 10y ago
      They are just command that you could execute manually (using ':' like in vim). The difference is that all the commands in this file are executed at startup. As I said, all the heavy lifting is done in scopes like %sh{ ... }. This way you can actually use any language you want, and it's only the piping you have to do through kakoune commands. Most common languages (like go) already have plugins to do some basic tasks like formatting. If you're interested in the editor, I would rather recommend reading the readme of the project[1]. There is a lot to read, and you can start making plugins once you understand it. [1] https://github.com/mawww/kakoune https://github.com/mawww/kakoune
pmontra 10y ago
The concept is interesting but do the videos work? I get only moving ghost images. Android Opera and FF.
ncd 10y ago
This looks awesome (although I think the name could use a little work). It also brings up a question I have for HN: Every few years, I make an attempt to learn to use one of the classic editors like vim or emacs, and inevitably give up after the enormous productivity drop I suffer when writing code. I just can't seem to pick up the muscle memory required to become fast with these tools, and the overwhelming array of customization options leaves me frustrated. The most annoying thing is that I want to learn one of these, because I think I'll enjoy it once I do. Any suggestions from people who have picked one up on how to accomplish this seemingly Herculean task? And, I suppose, I have another another question: is it worth it?
- gbersac 10y ago
  Definitely not. I learned vim for three month. After a vimrc of close to 150 lines, I had to admit that sublime text has more functionality than vim and all of them are far more difficult and slow to use (long and hard to memorize command names). It's even worst compared with IDEA. Now I only use vim as my default editor in terminal. Just use sublime, or even better, IDEA.
  - wtetzner 10y ago
    I don't use either editor, but just out of curiosity, what functionality is in Sublime that Vim is missing? Multiple cursors? Certain plugins?
    - gbersac 10y ago
      Mutli cursor. There is plugins which try to emulate it, but it either didn't work or was lacking a lot functionnality. Other things bothered me, but the lack of good multi cursor implementation was a reason to stop using vim by itself. Just can't live without it now.
      - Gorgor 10y ago
        I have trouble conceiving of a use case where macros or regex-replacement cannot do what multiple cursors do. Do you have one in mind?
keepper 10y ago
I'm sorry... but "kak"? I love/like vi[m], I love/like emacs... I ... never mind lol The new editing language does look great, and I like the idea of the piped filters... but I can't get over the name :-/
- kilian 10y ago
  Worth noting is "kak" is one of the (many) words in Dutch for "poo". I dabble in vim and it's my editor for when I quickly want to change stuff whilst in a terminal, but not enough to be "proficient" in it. As others have noted, I feel there could be a massive gain in editing if I were to get more acquainted with the many vi commands, but the initial productivity penalty has stopped me more than once from making it my default editor. Kakoune's mental model of commands seems friendlier, so maybe it will stick :)
  - athenot 10y ago
    Hopefully this is a temporary name. Investing in branding upfront can be a waste of time but if it picks up, it might be worth a more thoughtout and friendly name.
    - nerdponx 10y ago
      Could be `kk`
      - Kareeeeem 10y ago
        And that is short for cancer in Dutch, used as a swear word.
    - DamnYuppie 10y ago
      Why not just "ki"?
  - lisivka 10y ago
    Same here. «kaka» — poo/bad thing, «kakoune» — somebody who does lot of poo. :-) However, «vi» means visual, while it is the least visual editor among popular editors, so I expect by analogy that kak will be very good editor. Keep fingers crossed. :-)
kkotak 10y ago
One functionality I find missing in all modern code editors is - repeat action. This was present and extremely useful in, now extinct, Convergent Technology OS (CTOS) resident editor. In brief, it allowed users to repeat all the actions they performed on one-line of code, on another line of code. It's amazing how productive you can be when you have that feature. This goes beyond find & replace; It also helps format code, insert, replace multiple parts of the line, etc. all with one keystroke.
- makmanalp 10y ago
  Yep - this is "." in vim and it saves me so much work all the time.
- hobofan 10y ago
  I don't know what you are talking about. Every major editor I know has that functionality.
  - oblio 10y ago
    It does? I wouldn't mind finding out how Sublime, Atom and VSCode do it.
    - hobofan 10y ago
      Atom has [0] which I use from time to time. I don't use the other two, but as far as I understand Sublime has support for macros built-in, and VS Code is still pretty young and will probably get something similar once its ecosystem grows. I rarely use ad-hoc recorded macros. Like the author of Kakoune, I think multi-cursors feel much more natural. [0] https://atom.io/packages/atom-keyboard-macros https://atom.io/packages/atom-keyboard-macros
  - lisivka 10y ago
    I'm not a huge fan of vim: I used vim a lot for a 1,5 year, then switched to IDE with refactoring (CodeGuide was one of the first IDE's with refactoring for Java). When a IDE supports refactoring, e.g. it can swap order of arguments in calls to function, it helps a lot. But when the IDE does not support refactoring of language of your choice, vim can help to do a refactoring of code manually much faster. For example, I may use some shell commands to refactor bunch of js/html/css/java/sql code with single or few find and perl -pie commands, all at once. When I need to do an another refactoring, I can pickup previous refactoring command from shell history or I even can put command into script, so I will have my own refactoring tool. Regular expressions are fragile when used with code, but I can undo changes with git and repeat. They are saving lot of typing, so I prefer to spend few minutes in console than a hour in IDE. Vim has lot of commands built-in, so it's even easier to do a refactoring in Vim, but IDE's built-in refactoring is still better, when available.
greenspot 10y ago
If you are wondering why Kakoune and not Vim, the OP claims... (you find following passages later in his post and they don't reflect my opinion) > A design goal of Kakoune is to beat vim at its own game, while providing a cleaner editing model. > Kakoune manages to beat Vim at the keystroke count game in most cases, using much more idiomatic commands. > Kakoune provides an efficient code editing environment, both very predictible, hence scriptable, and very interactive. Its learning curve is considerably easier than Vim thanks to a more consistent design associated with strong discoverability, while still being faster (as in less keystrokes) in most use cases.
- laurent123456 10y ago
  This is also quite an important difference: > Kakoune’s grammar is object followed by verb, combined with instantaneous feedback, that means you always see the current object (In Kakoune we call that the selection) before you apply your change, which allows you to correct errors on the go.
  - OskarS 10y ago
    I'm thinking about whether this is a good idea. He gets vi/Vim's model slightly wrong by saying it's "verb then object". While that is true for some things (i.e. text objects, like "ciw" for "change inner word"), it's not true in general. The general rule is "verb then motion". In "dw" ("delete word"), the "w" doesn't represent an object, it represents a motion (going one word forward). It's the same motion that I can use for any command, mapping, or indeed for just moving through text. Let say I want to delete a word from somewhere in the middle of a line. I would then navigate to the line in question, then press something like "^wwwdw" (i.e. "move to the beginning of the line, move 3 words forwards, delete word"). The motion of the deletion is the same as the motion for navigation. How would that work if the motion comes first? Would I go "wwwwd"? Would that delete one word, or four? Would you use a different key for the motion and the text object? I don't think this is a bad idea, swapping the order. The thing about showing you what's about to happen is a great point (though Visual mode in vim works pretty well for this purpose). I'm just wondering if it's better in practice. I'm certainly willing to give it a shot.
eptcyka 10y ago
What I'm interested in is whether the editor will have nicer interfaces for plugins - async evaluation of things is a massive pain in vim. The same could be said for regular expressions to do syntax highlighting.
omtose 10y ago
As a user, I think this is the main reason why I like kakoune: > Another often overlooked property of using a text editing language is that it’s fun. Some other things that I like about it that are not mentioned: The author is responsive to feature requests and bugs on github. The codebase is very well-made, if you have any interest in C++ I recommend taking a look at it.
aurelien 10y ago
There is GNU Emacs, there is Vim and you make your choice here. The rest is just pale copies.
IshKebab 10y ago
Modal text editors are definitely not my thing, but anyway this looks like a huge improvement on vim. Still a shame that it is entirely console-based. It's 2016 people! We've had GUIs for literally decades.
- falcolas 10y ago
  What would a GUI bring to this that isn't possible in the console? You can use a mouse to issue commands to console programs, after all: if you want to use your mouse to scroll through or select regions of text, you can.
  - omtose 10y ago
    > What would a GUI bring to this that isn't possible in the console? Not being destructive of user input, for starters.
    - kaoD 10y ago
      Not sure I understand what you mean.
      - omtose 10y ago
        For example the fact that the terminal does not make any difference between <c-m> and <ret>. Or <c-i> and <tab>.
        falcolas 10y ago
        How is that destructive? Visual editors assign various non-editing tasks to command sequences as well. Pycharm moves the cursor around parenthesis with C-m for example, Cmd-M minimizes windows, and Cmd-I does formatting.
        omtose 10y ago
        I don't understand what you mean. It's destructive in the sense that the raw input is not even being passed to the application in the terminal. No applications running in the terminal will be able to tell the difference between these two different key presses.
SeanDav 10y ago
From the github docs: > " Due to Kakoune relying heavily on being in a Unix-like environment, no native Windows version is planned." Deal breaker right there. If I am going to go to the effort of learning a new editor, it better run on all reasonable platforms - like Vim does.
- falcolas 10y ago
  To be fair, vim is somewhere around a 4th class citizen on Windows. It works, but it ain't pretty. Plus, with the unix subsystem (minus bugs) you can still run this in Windows. That still amazes me.
  - MetaCosm 10y ago
    What exactly isn't pretty about vim (specifically gVim) on Windows?
    - nameless912 10y ago
      The default fonts, the menus, the menu icons, the font rendering, the inability to use many plugins....
- omtose 10y ago
  For what it's worth, it works properly on cygwin (and certainly the linux subsystem too). I know that the author uses it on cygwin too so there is at least some guarantee.
- grive 10y ago
  It is a sensible decision, as it will focus doing things right on that particular paradigm: UNIX. For example, this means that plugins trying to extend grammar analysis, will primarily try to rely on their already existing parsers and tools via the command line. This means a streamlined process to create plugins / extensions to the editor, and the function of the editor is well defined.
- notheguyouthink 10y ago
myth_drannon 10y ago
what's the font that is used on the screenshots ? I would love to try it in Pycharm IDE/Jetbrain products.
- mawww 10y ago
  The font is called terminus
dri_ft 10y ago
Looks like an excellent model. I'll probably stick with vim, at least for the time being, but I'm always glad to see new work being done on modal text editors. I agree that vim's model has certain shortcomings, and it's nice to see see someone trying to address them. The multiple selections thing looks really cool.
reitanqild 10y ago
A better vim sounds great. That said I suspect most people would be better off learning a good IDE properly, including but not limited to: * effective navigation and selection using modifier keys and search * built in refactoring * project wide as well as single file search/replace, -and this includes regex search AND replace. This should be quite doable in less than a week compared to a few months to get equally effective in vim. Edit: let me add that parts of this looks like a huge improvement over vim.
- kqr 10y ago
  But if you are like me and work in many different languages, you'll have to spend 10 weeks to learn 10 different IDEs, rather than 8 months to learn one Vim.
  - reitanqild 10y ago
    The ones I have used (IntelliJ, Netbeans and eclipse) were quite effortless to jump between. I doubt Visual Studio will be much harder. Jetbrains covers Ruby, Python, JS, C and more and it would surprise me bigtime if those language specific versions aren't quite similar to the plain Java version as well.
    - throwaway109211 10y ago
      I think Vim is far easier to learn than Visual Studio. The menus are completely unintuitive, bureaucratic and painful to use. I always use cl.exe from the command line with Makefiles.
      - gbersac 10y ago
        I think it is very hard to be more unintuitive than vim.
        throwaway991872 10y ago
        Vim is unintuitive at first, but there's excellent documentation. With Visual Studio, the documentation is horrible, you always encounter stale links to unorganized and regularly changing microsoft.com websites. Relatively basic things are left unexplained and documentation is outsourced to Stackoverflow: 1) How do I restore the output window I clicked it away in order to make the editor usable in the first place? 2) What the heck is a "project" and why do I need one? 3) Why do I need so many frigging clicks to get to the debugger (the debugger itself is nice though I have to admit)? The list goes on an on. All these things are far simpler with vim and gdb: Need to debug x87 fpu registers? One simple google search and you have an instructive plaintext website that tells you everything and off you go.
babo 10y ago
It would be interesting to see it as an editing mode in atom.io or vs code!
hans 10y ago
Pontificating but for ide + editor replacement: someday we'll see ai/ml features that aide in opening files and keeping the right blobs of code nearby, maybe pre fetch good goog links that can drop down on a whim panel. Even some kind of auto model visualizer that helps every so often like a replacement for the ignoble package mmanager side panel view. We're still so stuck on text editing.
- marktangotango 10y ago
  All this exists in various IDE's for various languages (except the prefetch of 'good' google links) re keeping related code globs around. In particular Netbeans IDE supports a lot of dynamic languages. It's php, python, and javascript plugins all offer project views other than "what's on the filesystem", intellisense, code completion as you type. I suggest spending time exploring existing options if one hasn't. RE editing text: whatever code object model one can imagine, it generally always serializes to text. I for one don't see the benefit of editing an abstract model in place of text. An example I liked was Fortress [1]. Fortress was a language that attempted to let users write code in mathematical notation using a special latex editor (iirc). It was found to be not a huge win, and they reverted to 'normal' syntax. This was one of Guy Steeles projects at sun. So having said that, there are languages where editing the model is editing text: Lisp and Scheme. [1] https://en.wikipedia.org/wiki/Fortress_(programming_language) https://en.wikipedia.org/wiki/Fortress_(programming_language...
- _binder 10y ago
  Reminds me of helm and ivy in emacs
- blakeyrat 10y ago
  I think we need to first get over the hurdle of "code == text". I mean, the features you talk about are great-- but right now I can't even embed a little vector graphic explaining a function's flow in my source file. Every time I've suggested using a file format that allows things like fonts, styles, embedded images, to write my code, the reaction is always an insanely irrational knee-jerk against it. (Seriously, try it out with your programmer colleagues.) (And to prod the bear a bit, a large part of the problem is the developers who insist in working in tools like the ones we're discussing here, designed in the '70s and using absolutely no technology that was invented after 1985 or so. Ludicrous. Imagine if any other industry worked that way!) Then a couple days later, you found out they spent like an hour making ASCII art of some diagram because they couldn't just paste the actual diagram into the code. Sigh. Reason #3136269 I don't get along with other programmers. I mean you're talking about advanced AI code that looks up Google links to explain code constructs, meanwhile 95% of the industry is using a code editor that doesn't even allow you to embed a link in a code file. (If you're lucky, it'll make an obvious URL clickable, that's about the best you get.)
msl09 10y ago
The videos don't seem to play on firefox 45.5.1
kahrkunne 10y ago
Interesting. Haven't seen a new modal editor in a while, nice to see some innovation there. How long until someone ports this to Emacs?
chrismorgan 10y ago
This webpage has the honour of causing my browser (Firefox Nightly, Windows, 64-bit) to crash outright. It’s been ages since that’s happened. Ah, the occasional joys of running a nightly browser as your primary browser!
- orng 10y ago
  The same happens for me on FF on Android. I tried three times and it crashes each time. A shame, the comments have intrigued me.
JadeNB 10y ago
I generally pass over mentions of new text editors because they seem to be either orthogonal to what makes Vim great, or else to approach Vim with the approach that it's mostly wrong—think of Cream, for example, which seems more about onboarding newbies than appealing to experienced users (which is fine!). I think of Neovim as an improvement for Vim scripters and coders, while aiming to provide mostly the same end-user experience, so I haven't really bothered with it. I'd discounted previous mentions of Kakoune, assuming that it was more of the same, but this discussion (and in particular greenspot's deservedly top-rated comment https://news.ycombinator.com/item?id=13166784 https://news.ycombinator.com/item?id=13166784 ) made me take a closer look, and I think I'll give it a try.
andrewfromx 10y ago
but when I ssh into a server it's 100% guaranteed vim or vi will be installed on it already. It will take years for kakoune to reach that state. Same with curl and grep. They are every where so I learn them.
equalarrow 10y ago
I don't want to belittle anyone's work or inventions, but I think modal editors are old and outdated. They've had their time in my mind. Bret Victor gave a great talk about programming and tools: https://vimeo.com/36579366 https://vimeo.com/36579366 His talks always blow me away.
- jstewartmobile 10y ago
  His demo is a neat parlor trick, but when you think about it, he's really just painting with javascript instead of a paint program. Introduce any kind of higher dimensionality into his model and it breaks.
- akkartik 10y ago
  On the contrary, my reaction to reading OP was, "wow, somebody brought Bret Victor's ideas to modal editors!" The goal of switching verb and object is precisely to stop drawing dead fish (http://worrydream.com/#!/StopDrawingDeadFish http://worrydream.com/#!/StopDrawingDeadFish)
hxegon 10y ago
You have my attention. :) edit: Wow, super excited to try this out.
vanderZwan 10y ago
> Interactivity comes by providing feedback on every commands, the inverted object then verb grammar makes that possible, every selection modification has direct visual feedback, regex based selections incrementally show what will get selected, including when the regular expression is invalid, and even yanking some text displays a message notifying how many selections were yanked. Did anyone else think of reverse Polish notation and concatenative languages like Forth when reading this paragraph?
geodel 10y ago
A few things I like: * No NodeJS/NPM * No Electron * No multi-threading
- buster 10y ago
  No multi threading is a plus?
  - geodel 10y ago
    From Design notes: > "No threading: multithreading is a hard problem, and is not well suited to a text editor: Either we want a direct result, and we need to be synchronous with the user, so getting a 4x speed up is meaningless, we need to have an algorithm which appears instantaneous the user. Or we want an asynchronous result, and then the processing is best left to a helper command which can be reused with other Unix tools." I agree with them. Multithreading today in all situations is like Fuzzy logic of yesteryears. It is suppose to make everything better.
    - buster 10y ago
      One of the big problems of editors like emacs and vim is that they haven't had means for background processing for years. And no, multithreading is not hard if you design for it. It is very hard if you need to add it as an afterthought. Some people would even say threads are easier then async.
DigitalJack 10y ago
It's pretty hard to find a link[0] to actually getting kakoune on the home page. Usually that sort of link at the bottom is an email URI and I try to avoid clicking on those. Based on the linked screenshot[1], perhaps the editor should be named "Clippy's Revenge" [0] https://github.com/mawww/kakoune https://github.com/mawww/kakoune [1] http://kakoune.org/img/screenshots/screenshot-tmux.gif http://kakoune.org/img/screenshots/screenshot-tmux.gif
- type0 10y ago
  "Clippy's Revenge" sounds like a cool name, at least it's more memorable than Kakoune.
cwp 10y ago
> Kakoune’s grammar is object followed by verb This is so important. It's the reason I've stuck by Quicksilver all these years, and avoided Spotlight and whatever Google's search bar thingy is called. I've never been interested in vi because the effort to reward ratio doesn't seem favourable, but I think I'll give Kakoune a try.
- eridius 10y ago
  Quicksilver, still? Why not move on to Alfred?
  - egypturnash 10y ago
    I'm not the person who mentioned QS but I'm still using it too. For me it's mostly inertia: Alfred can probably do everything I use QS for, but QS still works just fine, so why bother? When something breaks the 10% or so of QS's capabilities that I actually use beyond fixing, then I'll switch. ("Probably": last I tried using Alfred a few years ago, I think there was something I relied on QS to do that Alfred couldn't. I can't remember what it was, maybe Alfred does it now - but again, why bother? QS still does everything I want it to do.) Also QS's interface looks cooler than Alfred's to me. Aesthetics matter.
    - eridius 10y ago
      QS was seriously broken for a long time. I understand someone else finally picked it up and started fixing the bugs, but I don't know why anyone actually kept with QS during the long broken period. Even back when QS was under active development by the original author, it was still pretty buggy. I actually had a separate keyboard shortcuts app running in the background with a single shortcut which would relaunch QS for those times when QS decided to crash. I am curious what you relied on QS for that Alfred can't do. Everything I remember doing with QS is doable with Alfred.
      - cwp 10y ago
        The great thing about Quicksilver is the grammar - it's actually object, verb, indirect object. That lets you do things like <file>, <email to>, <person>. Alfred didn't have that basic structure when I tried it. I'm sure it's quite powerful, probably more so than QS given the latter's long stagnation. But I never bothered to figure out how to use Alfred effectively because QS is so easy and works great. There were a couple of bugs that were annoying for a while, but they've been fixed. Kakoune doesn't mention the "indirect object" part of the grammar, but apparently it'll prompt for more information when needed, so it's pretty close.
billconan 10y ago
I will give this a try. I had been a long time vim/emacs rejector. I used ide and sublime text for most of the time. But few weeks ago, I needed to program a server for deep learning. Because of the graphics driver on that server, there is really no option to run a gui application. So I had to learn vim. It turned out to be not that difficult to get used to it. The only complain I have is code navigation. The font size of the vim is fixed to the font size of the terminal. The text is relatively large, therefore the viewing window can only show few lines of code. Sometimes, I need to reference a previously defined variable or function of the same file, It's difficult to quickly navigate to the right place. With sublime text, it's mini map navigator is so convenient to allow me go back and forth between locations. With vim, however, I rely more on my memory. I need to go back once and remember everything, and then go to the end of the file to edit.
- Phlogistique 10y ago
  You might like the '*' and '#' keys, as well as marks, particularly "'.".
twblalock 10y ago
One of the nice things about being an Emacs user (hang in there, I have a real point about Vim to make) is that the concepts (especially non-modal editing) and the keyboard shortcuts map well to newer IDEs. I switch between IntelliJ and Emacs all day, and all I had to do to become comfortable is choose the Emacs keyboard preset in the IntelliJ preferences. The same is true for Eclipse and Visual Studio. The Emacs paradigm is a lot more similar to contemporary IDEs than the Vim paradigm, and that makes it a lot easier to switch back and forth. While a better Vim is a nice goal, I don't see how it will bridge the gap between Vim and newer editors/IDEs unless it includes some fairly fundamental changes to the Vim paradigm. But then it wouldn't be a better Vim -- it would be something different enough that Vim users probably wouldn't like it. I suspect that Vim and modern editors/IDEs are doomed to remain divergent forever.
- SatvikBeri 10y ago
  FWIW, I'm a 6-year Vim user, I have the same great experience using Jetbrains IDEs with the Vim presets.
- QuadrupleA 10y ago
  Just a quick note that I've been using Visual Studio and the VsVim plugin happily for years. They work great together. All the Vim-fu plus real keyword completion, jumping to definitions, instant renaming of any function/variable (VAX plugin) etc.
- scaryclam 10y ago
  I find that nearly all editors have VIM "mode" that will allow you to just use the vim key bindings, so it's not really a problem swapping between two editors. They tend to have an emacs mode as well, in case you're interested in using your emacs keys.
  - brennen 10y ago
    Unfortunately, this is superficially true but not in practice all that helpful for a lot of us. Most vim-style input modes or plugins for other editors are woefully lacking, and even very good ones (evil mode) seem to differ enough to be uncomfortable for a subset of long-term vim users. Like: I've used Emacs extensively in the past, and certainly _could_ switch to evil if need be, but a few days of recent effort showed me that the switching costs are higher than I'm willing to pay right now, and it's not clear I'd be any better off in the end. Whatever the infelicities of vim's implementation (there are certainly plenty), I think there's a tendency to underestimate the expressive nuance and (for lack of better words) complex texture of the interface.
mponw 10y ago
I started a similar project in 2013, sadly never delivered a working prototype. Its name was going to be "Kuji Editor", basically an editor in visual mode by default and with context-verb grammar instead of vi's verb-object grammar. I knew this would represent a big improvement over other editors because of a more intuitive and modern approach leading to a better workflow. I started with building the UI in PyGame but never got further than that... (I am really disappointed I didn't spend more time on this now I see the attention Kakoune gets. I would have loved the feeling of contributing something truly innovative... well...). Congrats to Maxime!
farresito 10y ago
I was pleasantly surprised at how good it is. Definitely keeping an eye on it.
JepZ 10y ago
The 'd2tf' example is just wrong... after realizing I didn't hit the right 'f' I would just press '.' (not 'ud2tf')... I think I will stay with vim for now, also the discoverability could be better... Btw. mixing vim with tmux also solves the 'command line next to editor' problem.
Rainymood 10y ago
Interesting, as a long term Vim user I might try this out. Currently invested some time in Spacemacs and I don't want to jump around too much. It really needs a catchier name though. We have Vim. Spacemacs. Emacs. Kakoune sounds a bit foreign imho.
visarga 10y ago
Problem with all these hotkeys is discoverability and memory. In the end, I use just a few well known hotkeys. It's useless to define hundreds of them. I don't like modal editors especially because keys have even more functions then, which I have to remember.
tschellenbach 10y ago
Interesting, but how will they make money to fund continued development? So many editors show great promise to slowly disappear and fade away because of budget issues.
omtinez 10y ago
Shameless plug: I have been working on my own code editor as well, I wanted something between Notepad++ and Jupyter Notebooks; I called it TeIDE: https://github.com/omtinez/teide https://github.com/omtinez/teide Fully open source, built on Polymer and currently working on a plugin/action model to enable users to execute custom commands on the underlying shell. Accepting pull requests and all forms of feedback :-)
saosebastiao 10y ago
I love this idea, and look forward to trying it when I have a little more disposable time to learn something new. I just want to point out one thing: While it is admirable that this project sticks to just text editing, our text editors often form a part of a system. This includes IDEs, shells and interpreters, and the OS itself. One of the missing "modes" of vim is a yield-to-something-other-than-editor mode. Because we don't have this, any time I use vim or a vim compatibility layer, I end up having to remap keys from their defaults to something that I have trouble remembering and is completely different from the docs. I hate remapping keys. Give us a mode that allows us to keep the rest of our ecosystem intact.
kstenerud 10y ago
Blah blah blah another "modal editing is better" article. And once again, I'm not impressed. You may not like GUIs, but I do. You may think that keeping your hands on the keyboard and off the mouse makes you more productive, but I don't. We all have our preferences. Yours are not better than mine. End of story.
- zem 10y ago
  they're not mutually exclusive. vim's modal features are handy even if you use gvim - e.g. you could select a range of text with the mouse and use y to yank it because you were in editing rather than insert mode
gdmeteor 10y ago
I've actually never heard of Kakoune. And I'm not too familiar with verb based text editors in general. I've been using Visual Studio Code recently and like it functionality wise. http://jsdiaries.com/2016/11/27/visual-studio-code-features-part-1/ http://jsdiaries.com/2016/11/27/visual-studio-code-features-... I may move on to a verb based editor like this as my projects getting more complex and navigating through verb commands is a must. But can someone tell me what languages would benefit most from an editor like Kakoune? I'm assuming creating macros would be a big part of using it ?
nonsince 10y ago
This is awesome, I only wish it was a mode integrated into Emacs, like evil-mode. I can't afford to give up the debugging, completion etc. that I get as part of emacs, but I would love to use this in my day-to-day flow.
hugozap 10y ago
I moved from Sublime Text to vim. Tried emacs first but for some reason it didn't click. vim was much easier to start with and I see the benefits of mastering modal editing. It's not about typing faster, but developing the muscle memory to transform text without thinking about it. That's really powerful.
jonahrd 10y ago
A few questions after playing around with this for a bit: After making a complicated selection, doing something else, I want to go back to that selection easily. Is there a selection history? A way to execute the last selection? I tried running a shell command that waited on input and kak hung waiting for the command to finish. is there a way to kill the command? Or better, a way to interact with the command after its running? I like it so far!
0xFFFFFF 10y ago
I'm still waiting for someone to do a modal abstract syntax tree editor. You would only type text when naming something, the other mode would be for navigating the AST.
- toxicFork 10y ago
  Sounds like a visual scripting system with low level constructs.
  - 0xFFFFFF 10y ago
    Visual scripting is nice in that you can have a seperate presentation layer on top of the language syntax. There's a lot of potential in improved readability that way I think. Most visual scripting depends on mouse actions, which is kind of slow and I suspect a big reason why programmers dislike it so much.
- nrub 10y ago
  Have you used paredit-mode in emacs with a lisp dialect? Getting proficient with this mode can be a lot like what you describe. Paredit let's you navigate and edit the tree structure of lisp code pretty effectively. It's not inherently a modal paradigm, but I used it evil-mode successfully. I'd imagine what you describe could be a refinement on that technique. Lisp lends itself well to this type of editing due to it's lack of syntax. Other languages are more difficult.
eridius 10y ago
This looks very interesting. But why does this whole site try to use WebM video even on browsers that don't support it? When viewing this site in Safari, there's a bunch of broken videos scattered around.
deft 10y ago
The features demostrated here are almost the exact ones I'm looking to do in Vim (I've only been using for a few months) and the way they describe them here makes them so simple. I hope this continues to mature!
asimjalis 10y ago
Neat. One question: How can I script it? What is the scripting language for customizing the editor? I couldn’t find information on this in the documentation.
- wtetzner 10y ago
  This thread explains that you script it using shell commands: https://news.ycombinator.com/item?id=13166635 https://news.ycombinator.com/item?id=13166635
  - flukus 10y ago
    So it's not possible to have something like vims quickfix?
BrandoElFollito 10y ago
vi [vee-ay] : Aztec expression for "how the fuck do I get off this shit". Esc Esc : q!
exabrial 10y ago
I think editors provide at least two more things: Code completion and global refactoring. Eclipse/IntelliJ users in the Java world can pound out entire programs in seconds using nothing but keyboard shortcuts. Are there features like this for other languages?
dpc_pw 10y ago
I really like it. However given how confusing for my Vim muscle memory a switching would be, I would have to make sure the ecosystem around it is good enough. Basic programming languages highlights and completions and similar tools.
sushisource 10y ago
This might get lost in here, but one thing that I'm dissapointed by is I love this idea, it looks fantastic, and I'm a vim "user" that would love to switch. But I put user in quotes because really I use IntelliJ or VS or whatever, with the vim plugin, for the rich refactoring / autocomplete support which, for most languages, is awful to try to integrate with a command line editor like this. Anyone know if the author plans to make a plugin client? That would be amazing.
- farresito 10y ago
  The problem, I think, is on Intellij's or VS' side rather than on Kakoune's; otherwise, we would already have an Intellij client based on neovim. I'm in a similar boat to you, but I don't think there is much hope unless those IDEs actually do something to make this viable.
  - sushisource 10y ago
    Yeah, you're probably right. I was sort of implying "with the understanding it's unlikely any of the IDE makers are going to do this, it would be nice to have the common code separate so a plugin wrapper is easy". Something along those lines.
voaie 10y ago
Finally, the legacy burden of vim and neovim gone, and a whole new world :D Thank you a lot!
FrancoDiaz 10y ago
I'm glad to see someone thinking outside of the vi box when it comes to modal editing. But the problem is that editors aren't very useful on their own without an ecosystem of development plugins. I'd love to see this ported to VSCode.
ferologics 10y ago
This reminds me of "vis" from about a year ago - https://github.com/martanne/vis https://github.com/martanne/vis
rgun 10y ago
How do you pronounce 'kakoune'? Some people are already using 'kak' instead of 'kakoune', IMO 'kak' will be a better name.
- nedt 10y ago
  Kak sounds like poo-poo in german and similar languages. It's even a loanword in english.
jerkstate 10y ago
I tried this editor out and the most maddening thing was figuring out how to reduce multiple cursors back down to one. I finally figured out - by accident - that pressing the space bar reduces your number of cursors down to one. The documentation needs to make this basic, necessary key-command a lot more obvious.
etruong42 10y ago
I see many valuable feature, such as the highlighting and the tooltips. I wonder if these could have been expediently implemented as VIM plugins - perhaps each feature could have been a VIM plugin so that people can pick and choose which feature set they wanted.
iplog 10y ago
Really interesting project and looking forward to having time to play a bit more with it. After trying it for the first time and reading the documentation I have the impression that the `alt` key is used a lot as a modifier key for basic things such as selecting inner objects. One thing I love about Vi and Vim is that most it tries to reduce the usage of modifier keys which is awesome when you are touch typing. I would love to know why the author chose the `alt` key and what the other options were. That's a great project and I'm sure it could help a lot of developers to understand modal mode. Great work!
nikolay 10y ago
Why not write it in Rust though like Google's Xi [0]? [0]: https://github.com/google/xi-editor https://github.com/google/xi-editor
- steveklabnik 10y ago
  > I have been working, for the last 5 years, Rust was very, very different five years ago.
  - nikolay 10y ago
    Sorry, I've missed that!
bsg75 10y ago
Boost dependency, which I always have bad luck getting to build in a reasonable time. Isn't Boost going away?

631 points by petepete 10y ago

I liked the ideas and especially the paperclip :) I couldn't find whether it is completely written from scratch or a vim fork? If not, why is it not a vim fork?

petepete 10y ago
I believe it's a complete re-implementation. I think with so many 'deep' changes to the functionality, rewriting would probably be easier than forking.
pietrofmaggi 10y ago
From the github repository: https://github.com/mawww/kakoune https://github.com/mawww/kakoune reply Vim inspired — Faster as in less keystrokes — Multiple selections — Orthogonal design
omtose 10y ago
You can also use a cat or nothing as "helper".
rz2k 10y ago
The code statistics on github[1] show almost all C++, while vim is written in C. According to the author the project began as a reimplementation or merely a rewrite of vim then turned into a more ambitious reimagining of how to design a modal editor. [1] https://github.com/mawww/kakoune https://github.com/mawww/kakoune
doppioandante 10y ago
It is written from scratch in a very modern C++ style, I advise every C++ programmer to look at it. Also the code is quite well organized.

diggan 10y ago

Might be a good idea to include a link to this new editor at least somewhere in the text. I couldn't find even one little link...

pietrofmaggi 10y ago
You can find the editor source, and installation instructions on github: https://github.com/mawww/kakoune https://github.com/mawww/kakoune
- diggan 10y ago
  Thanks! However, my point was that people shouldn't have to read comments on HN to be able to find the editor (I thank you for helping me though!) that someone wrote a whole blogpost about.
  - notheguyouthink 10y ago
    I agree with you, though it's a frequent issue that blog posts don't link back to the main site. With that said, it's fairly obvious to go to the root domain for something like a blog post, and that's how i found it. Definitely should include a link, though.

nerdponx 10y ago

Looks great. Does it have a different scripting language, or is it still VimL? What kind of plugin support does it have? Is it embeddable? Does it have a messaging API like Neovim? How well does it handle long text lines and long documents?

omtose 10y ago
Some answers as a user: No scripting language, most of the heavy lifting done in plugin is through shell calls (asynchronously or not). Example here [1]. I personally think that it's kinda hard to grok to be honest. Thanks to the client server architecture, it is possible to make an external UI[2]. There is no line wrapping currently. Don't know about long documents, but the editor in general is very efficient. [1] https://github.com/mawww/kakoune/blob/master/rc/core/grep.kak https://github.com/mawww/kakoune/blob/master/rc/core/grep.ka... [2] https://github.com/mawww/kakoune/blob/master/doc/json_ui.asciidoc https://github.com/mawww/kakoune/blob/master/doc/json_ui.asc...
- notheguyouthink 10y ago
  What is your 1st example exactly? I mean, if Kak doesn't come with a scripting language, then what language is that exactly? This is an important note to me, because i imagine i'll have to implement my own tools for common language tasks like Gofmt and Goimport. Honestly, it would be cool if i could write plugins in any language i want, ie if it fully uses a backend editor server API.
  - omtose 10y ago
    They are just command that you could execute manually (using ':' like in vim). The difference is that all the commands in this file are executed at startup. As I said, all the heavy lifting is done in scopes like %sh{ ... }. This way you can actually use any language you want, and it's only the piping you have to do through kakoune commands. Most common languages (like go) already have plugins to do some basic tasks like formatting. If you're interested in the editor, I would rather recommend reading the readme of the project[1]. There is a lot to read, and you can start making plugins once you understand it. [1] https://github.com/mawww/kakoune https://github.com/mawww/kakoune

pmontra 10y ago

The concept is interesting but do the videos work? I get only moving ghost images. Android Opera and FF.

ncd 10y ago

This looks awesome (although I think the name could use a little work). It also brings up a question I have for HN: Every few years, I make an attempt to learn to use one of the classic editors like vim or emacs, and inevitably give up after the enormous productivity drop I suffer when writing code. I just can't seem to pick up the muscle memory required to become fast with these tools, and the overwhelming array of customization options leaves me frustrated. The most annoying thing is that I want to learn one of these, because I think I'll enjoy it once I do. Any suggestions from people who have picked one up on how to accomplish this seemingly Herculean task? And, I suppose, I have another another question: is it worth it?

gbersac 10y ago
Definitely not. I learned vim for three month. After a vimrc of close to 150 lines, I had to admit that sublime text has more functionality than vim and all of them are far more difficult and slow to use (long and hard to memorize command names). It's even worst compared with IDEA. Now I only use vim as my default editor in terminal. Just use sublime, or even better, IDEA.
- wtetzner 10y ago
  I don't use either editor, but just out of curiosity, what functionality is in Sublime that Vim is missing? Multiple cursors? Certain plugins?
  - gbersac 10y ago
    Mutli cursor. There is plugins which try to emulate it, but it either didn't work or was lacking a lot functionnality. Other things bothered me, but the lack of good multi cursor implementation was a reason to stop using vim by itself. Just can't live without it now.
    - Gorgor 10y ago
      I have trouble conceiving of a use case where macros or regex-replacement cannot do what multiple cursors do. Do you have one in mind?

keepper 10y ago

I'm sorry... but "kak"? I love/like vi[m], I love/like emacs... I ... never mind lol The new editing language does look great, and I like the idea of the piped filters... but I can't get over the name :-/

kilian 10y ago
Worth noting is "kak" is one of the (many) words in Dutch for "poo". I dabble in vim and it's my editor for when I quickly want to change stuff whilst in a terminal, but not enough to be "proficient" in it. As others have noted, I feel there could be a massive gain in editing if I were to get more acquainted with the many vi commands, but the initial productivity penalty has stopped me more than once from making it my default editor. Kakoune's mental model of commands seems friendlier, so maybe it will stick :)
- athenot 10y ago
  Hopefully this is a temporary name. Investing in branding upfront can be a waste of time but if it picks up, it might be worth a more thoughtout and friendly name.
  - nerdponx 10y ago
    Could be `kk`
    - Kareeeeem 10y ago
      And that is short for cancer in Dutch, used as a swear word.
  - DamnYuppie 10y ago
    Why not just "ki"?
- lisivka 10y ago
  Same here. «kaka» — poo/bad thing, «kakoune» — somebody who does lot of poo. :-) However, «vi» means visual, while it is the least visual editor among popular editors, so I expect by analogy that kak will be very good editor. Keep fingers crossed. :-)

kkotak 10y ago

One functionality I find missing in all modern code editors is - repeat action. This was present and extremely useful in, now extinct, Convergent Technology OS (CTOS) resident editor. In brief, it allowed users to repeat all the actions they performed on one-line of code, on another line of code. It's amazing how productive you can be when you have that feature. This goes beyond find & replace; It also helps format code, insert, replace multiple parts of the line, etc. all with one keystroke.

makmanalp 10y ago
Yep - this is "." in vim and it saves me so much work all the time.
hobofan 10y ago
I don't know what you are talking about. Every major editor I know has that functionality.
- oblio 10y ago
  It does? I wouldn't mind finding out how Sublime, Atom and VSCode do it.
  - hobofan 10y ago
    Atom has [0] which I use from time to time. I don't use the other two, but as far as I understand Sublime has support for macros built-in, and VS Code is still pretty young and will probably get something similar once its ecosystem grows. I rarely use ad-hoc recorded macros. Like the author of Kakoune, I think multi-cursors feel much more natural. [0] https://atom.io/packages/atom-keyboard-macros https://atom.io/packages/atom-keyboard-macros
- lisivka 10y ago
  I'm not a huge fan of vim: I used vim a lot for a 1,5 year, then switched to IDE with refactoring (CodeGuide was one of the first IDE's with refactoring for Java). When a IDE supports refactoring, e.g. it can swap order of arguments in calls to function, it helps a lot. But when the IDE does not support refactoring of language of your choice, vim can help to do a refactoring of code manually much faster. For example, I may use some shell commands to refactor bunch of js/html/css/java/sql code with single or few find and perl -pie commands, all at once. When I need to do an another refactoring, I can pickup previous refactoring command from shell history or I even can put command into script, so I will have my own refactoring tool. Regular expressions are fragile when used with code, but I can undo changes with git and repeat. They are saving lot of typing, so I prefer to spend few minutes in console than a hour in IDE. Vim has lot of commands built-in, so it's even easier to do a refactoring in Vim, but IDE's built-in refactoring is still better, when available.

greenspot 10y ago

If you are wondering why Kakoune and not Vim, the OP claims... (you find following passages later in his post and they don't reflect my opinion) > A design goal of Kakoune is to beat vim at its own game, while providing a cleaner editing model. > Kakoune manages to beat Vim at the keystroke count game in most cases, using much more idiomatic commands. > Kakoune provides an efficient code editing environment, both very predictible, hence scriptable, and very interactive. Its learning curve is considerably easier than Vim thanks to a more consistent design associated with strong discoverability, while still being faster (as in less keystrokes) in most use cases.

laurent123456 10y ago
This is also quite an important difference: > Kakoune’s grammar is object followed by verb, combined with instantaneous feedback, that means you always see the current object (In Kakoune we call that the selection) before you apply your change, which allows you to correct errors on the go.
- OskarS 10y ago
  I'm thinking about whether this is a good idea. He gets vi/Vim's model slightly wrong by saying it's "verb then object". While that is true for some things (i.e. text objects, like "ciw" for "change inner word"), it's not true in general. The general rule is "verb then motion". In "dw" ("delete word"), the "w" doesn't represent an object, it represents a motion (going one word forward). It's the same motion that I can use for any command, mapping, or indeed for just moving through text. Let say I want to delete a word from somewhere in the middle of a line. I would then navigate to the line in question, then press something like "^wwwdw" (i.e. "move to the beginning of the line, move 3 words forwards, delete word"). The motion of the deletion is the same as the motion for navigation. How would that work if the motion comes first? Would I go "wwwwd"? Would that delete one word, or four? Would you use a different key for the motion and the text object? I don't think this is a bad idea, swapping the order. The thing about showing you what's about to happen is a great point (though Visual mode in vim works pretty well for this purpose). I'm just wondering if it's better in practice. I'm certainly willing to give it a shot.

eptcyka 10y ago

What I'm interested in is whether the editor will have nicer interfaces for plugins - async evaluation of things is a massive pain in vim. The same could be said for regular expressions to do syntax highlighting.

omtose 10y ago

As a user, I think this is the main reason why I like kakoune: > Another often overlooked property of using a text editing language is that it’s fun. Some other things that I like about it that are not mentioned: The author is responsive to feature requests and bugs on github. The codebase is very well-made, if you have any interest in C++ I recommend taking a look at it.

aurelien 10y ago

There is GNU Emacs, there is Vim and you make your choice here. The rest is just pale copies.

IshKebab 10y ago

Modal text editors are definitely not my thing, but anyway this looks like a huge improvement on vim. Still a shame that it is entirely console-based. It's 2016 people! We've had GUIs for literally decades.

falcolas 10y ago
What would a GUI bring to this that isn't possible in the console? You can use a mouse to issue commands to console programs, after all: if you want to use your mouse to scroll through or select regions of text, you can.
- omtose 10y ago
  > What would a GUI bring to this that isn't possible in the console? Not being destructive of user input, for starters.
  - kaoD 10y ago
    Not sure I understand what you mean.
    - omtose 10y ago
      For example the fact that the terminal does not make any difference between <c-m> and <ret>. Or <c-i> and <tab>.
      - falcolas 10y ago
        How is that destructive? Visual editors assign various non-editing tasks to command sequences as well. Pycharm moves the cursor around parenthesis with C-m for example, Cmd-M minimizes windows, and Cmd-I does formatting.
        omtose 10y ago
        I don't understand what you mean. It's destructive in the sense that the raw input is not even being passed to the application in the terminal. No applications running in the terminal will be able to tell the difference between these two different key presses.

SeanDav 10y ago

From the github docs: > " Due to Kakoune relying heavily on being in a Unix-like environment, no native Windows version is planned." Deal breaker right there. If I am going to go to the effort of learning a new editor, it better run on all reasonable platforms - like Vim does.

falcolas 10y ago
To be fair, vim is somewhere around a 4th class citizen on Windows. It works, but it ain't pretty. Plus, with the unix subsystem (minus bugs) you can still run this in Windows. That still amazes me.
- MetaCosm 10y ago
  What exactly isn't pretty about vim (specifically gVim) on Windows?
  - nameless912 10y ago
    The default fonts, the menus, the menu icons, the font rendering, the inability to use many plugins....
omtose 10y ago
For what it's worth, it works properly on cygwin (and certainly the linux subsystem too). I know that the author uses it on cygwin too so there is at least some guarantee.
grive 10y ago
It is a sensible decision, as it will focus doing things right on that particular paradigm: UNIX. For example, this means that plugins trying to extend grammar analysis, will primarily try to rely on their already existing parsers and tools via the command line. This means a streamlined process to create plugins / extensions to the editor, and the function of the editor is well defined.
notheguyouthink 10y ago

myth_drannon 10y ago

what's the font that is used on the screenshots ? I would love to try it in Pycharm IDE/Jetbrain products.

mawww 10y ago
The font is called terminus

dri_ft 10y ago

Looks like an excellent model. I'll probably stick with vim, at least for the time being, but I'm always glad to see new work being done on modal text editors. I agree that vim's model has certain shortcomings, and it's nice to see see someone trying to address them. The multiple selections thing looks really cool.

reitanqild 10y ago

A better vim sounds great. That said I suspect most people would be better off learning a good IDE properly, including but not limited to: * effective navigation and selection using modifier keys and search * built in refactoring * project wide as well as single file search/replace, -and this includes regex search AND replace. This should be quite doable in less than a week compared to a few months to get equally effective in vim. Edit: let me add that parts of this looks like a huge improvement over vim.

kqr 10y ago
But if you are like me and work in many different languages, you'll have to spend 10 weeks to learn 10 different IDEs, rather than 8 months to learn one Vim.
- reitanqild 10y ago
  The ones I have used (IntelliJ, Netbeans and eclipse) were quite effortless to jump between. I doubt Visual Studio will be much harder. Jetbrains covers Ruby, Python, JS, C and more and it would surprise me bigtime if those language specific versions aren't quite similar to the plain Java version as well.
  - throwaway109211 10y ago
    I think Vim is far easier to learn than Visual Studio. The menus are completely unintuitive, bureaucratic and painful to use. I always use cl.exe from the command line with Makefiles.
    - gbersac 10y ago
      I think it is very hard to be more unintuitive than vim.
      - throwaway991872 10y ago
        Vim is unintuitive at first, but there's excellent documentation. With Visual Studio, the documentation is horrible, you always encounter stale links to unorganized and regularly changing microsoft.com websites. Relatively basic things are left unexplained and documentation is outsourced to Stackoverflow: 1) How do I restore the output window I clicked it away in order to make the editor usable in the first place? 2) What the heck is a "project" and why do I need one? 3) Why do I need so many frigging clicks to get to the debugger (the debugger itself is nice though I have to admit)? The list goes on an on. All these things are far simpler with vim and gdb: Need to debug x87 fpu registers? One simple google search and you have an instructive plaintext website that tells you everything and off you go.

babo 10y ago

It would be interesting to see it as an editing mode in atom.io or vs code!

hans 10y ago

Pontificating but for ide + editor replacement: someday we'll see ai/ml features that aide in opening files and keeping the right blobs of code nearby, maybe pre fetch good goog links that can drop down on a whim panel. Even some kind of auto model visualizer that helps every so often like a replacement for the ignoble package mmanager side panel view. We're still so stuck on text editing.

marktangotango 10y ago
All this exists in various IDE's for various languages (except the prefetch of 'good' google links) re keeping related code globs around. In particular Netbeans IDE supports a lot of dynamic languages. It's php, python, and javascript plugins all offer project views other than "what's on the filesystem", intellisense, code completion as you type. I suggest spending time exploring existing options if one hasn't. RE editing text: whatever code object model one can imagine, it generally always serializes to text. I for one don't see the benefit of editing an abstract model in place of text. An example I liked was Fortress [1]. Fortress was a language that attempted to let users write code in mathematical notation using a special latex editor (iirc). It was found to be not a huge win, and they reverted to 'normal' syntax. This was one of Guy Steeles projects at sun. So having said that, there are languages where editing the model is editing text: Lisp and Scheme. [1] https://en.wikipedia.org/wiki/Fortress_(programming_language) https://en.wikipedia.org/wiki/Fortress_(programming_language...
_binder 10y ago
Reminds me of helm and ivy in emacs
blakeyrat 10y ago
I think we need to first get over the hurdle of "code == text". I mean, the features you talk about are great-- but right now I can't even embed a little vector graphic explaining a function's flow in my source file. Every time I've suggested using a file format that allows things like fonts, styles, embedded images, to write my code, the reaction is always an insanely irrational knee-jerk against it. (Seriously, try it out with your programmer colleagues.) (And to prod the bear a bit, a large part of the problem is the developers who insist in working in tools like the ones we're discussing here, designed in the '70s and using absolutely no technology that was invented after 1985 or so. Ludicrous. Imagine if any other industry worked that way!) Then a couple days later, you found out they spent like an hour making ASCII art of some diagram because they couldn't just paste the actual diagram into the code. Sigh. Reason #3136269 I don't get along with other programmers. I mean you're talking about advanced AI code that looks up Google links to explain code constructs, meanwhile 95% of the industry is using a code editor that doesn't even allow you to embed a link in a code file. (If you're lucky, it'll make an obvious URL clickable, that's about the best you get.)

msl09 10y ago

The videos don't seem to play on firefox 45.5.1

kahrkunne 10y ago

Interesting. Haven't seen a new modal editor in a while, nice to see some innovation there. How long until someone ports this to Emacs?

chrismorgan 10y ago

This webpage has the honour of causing my browser (Firefox Nightly, Windows, 64-bit) to crash outright. It’s been ages since that’s happened. Ah, the occasional joys of running a nightly browser as your primary browser!

orng 10y ago
The same happens for me on FF on Android. I tried three times and it crashes each time. A shame, the comments have intrigued me.

JadeNB 10y ago

I generally pass over mentions of new text editors because they seem to be either orthogonal to what makes Vim great, or else to approach Vim with the approach that it's mostly wrong—think of Cream, for example, which seems more about onboarding newbies than appealing to experienced users (which is fine!). I think of Neovim as an improvement for Vim scripters and coders, while aiming to provide mostly the same end-user experience, so I haven't really bothered with it. I'd discounted previous mentions of Kakoune, assuming that it was more of the same, but this discussion (and in particular greenspot's deservedly top-rated comment https://news.ycombinator.com/item?id=13166784 https://news.ycombinator.com/item?id=13166784 ) made me take a closer look, and I think I'll give it a try.

andrewfromx 10y ago

but when I ssh into a server it's 100% guaranteed vim or vi will be installed on it already. It will take years for kakoune to reach that state. Same with curl and grep. They are every where so I learn them.

equalarrow 10y ago

I don't want to belittle anyone's work or inventions, but I think modal editors are old and outdated. They've had their time in my mind. Bret Victor gave a great talk about programming and tools: https://vimeo.com/36579366 https://vimeo.com/36579366 His talks always blow me away.

jstewartmobile 10y ago
His demo is a neat parlor trick, but when you think about it, he's really just painting with javascript instead of a paint program. Introduce any kind of higher dimensionality into his model and it breaks.
akkartik 10y ago
On the contrary, my reaction to reading OP was, "wow, somebody brought Bret Victor's ideas to modal editors!" The goal of switching verb and object is precisely to stop drawing dead fish (http://worrydream.com/#!/StopDrawingDeadFish http://worrydream.com/#!/StopDrawingDeadFish)

hxegon 10y ago

You have my attention. :) edit: Wow, super excited to try this out.

vanderZwan 10y ago

> Interactivity comes by providing feedback on every commands, the inverted object then verb grammar makes that possible, every selection modification has direct visual feedback, regex based selections incrementally show what will get selected, including when the regular expression is invalid, and even yanking some text displays a message notifying how many selections were yanked. Did anyone else think of reverse Polish notation and concatenative languages like Forth when reading this paragraph?

geodel 10y ago

A few things I like: * No NodeJS/NPM * No Electron * No multi-threading

buster 10y ago
No multi threading is a plus?
- geodel 10y ago
  From Design notes: > "No threading: multithreading is a hard problem, and is not well suited to a text editor: Either we want a direct result, and we need to be synchronous with the user, so getting a 4x speed up is meaningless, we need to have an algorithm which appears instantaneous the user. Or we want an asynchronous result, and then the processing is best left to a helper command which can be reused with other Unix tools." I agree with them. Multithreading today in all situations is like Fuzzy logic of yesteryears. It is suppose to make everything better.
  - buster 10y ago
    One of the big problems of editors like emacs and vim is that they haven't had means for background processing for years. And no, multithreading is not hard if you design for it. It is very hard if you need to add it as an afterthought. Some people would even say threads are easier then async.

DigitalJack 10y ago

It's pretty hard to find a link[0] to actually getting kakoune on the home page. Usually that sort of link at the bottom is an email URI and I try to avoid clicking on those. Based on the linked screenshot[1], perhaps the editor should be named "Clippy's Revenge" [0] https://github.com/mawww/kakoune https://github.com/mawww/kakoune [1] http://kakoune.org/img/screenshots/screenshot-tmux.gif http://kakoune.org/img/screenshots/screenshot-tmux.gif

type0 10y ago
"Clippy's Revenge" sounds like a cool name, at least it's more memorable than Kakoune.

cwp 10y ago

> Kakoune’s grammar is object followed by verb This is so important. It's the reason I've stuck by Quicksilver all these years, and avoided Spotlight and whatever Google's search bar thingy is called. I've never been interested in vi because the effort to reward ratio doesn't seem favourable, but I think I'll give Kakoune a try.

eridius 10y ago
Quicksilver, still? Why not move on to Alfred?
- egypturnash 10y ago
  I'm not the person who mentioned QS but I'm still using it too. For me it's mostly inertia: Alfred can probably do everything I use QS for, but QS still works just fine, so why bother? When something breaks the 10% or so of QS's capabilities that I actually use beyond fixing, then I'll switch. ("Probably": last I tried using Alfred a few years ago, I think there was something I relied on QS to do that Alfred couldn't. I can't remember what it was, maybe Alfred does it now - but again, why bother? QS still does everything I want it to do.) Also QS's interface looks cooler than Alfred's to me. Aesthetics matter.
  - eridius 10y ago
    QS was seriously broken for a long time. I understand someone else finally picked it up and started fixing the bugs, but I don't know why anyone actually kept with QS during the long broken period. Even back when QS was under active development by the original author, it was still pretty buggy. I actually had a separate keyboard shortcuts app running in the background with a single shortcut which would relaunch QS for those times when QS decided to crash. I am curious what you relied on QS for that Alfred can't do. Everything I remember doing with QS is doable with Alfred.
    - cwp 10y ago
      The great thing about Quicksilver is the grammar - it's actually object, verb, indirect object. That lets you do things like <file>, <email to>, <person>. Alfred didn't have that basic structure when I tried it. I'm sure it's quite powerful, probably more so than QS given the latter's long stagnation. But I never bothered to figure out how to use Alfred effectively because QS is so easy and works great. There were a couple of bugs that were annoying for a while, but they've been fixed. Kakoune doesn't mention the "indirect object" part of the grammar, but apparently it'll prompt for more information when needed, so it's pretty close.

billconan 10y ago

I will give this a try. I had been a long time vim/emacs rejector. I used ide and sublime text for most of the time. But few weeks ago, I needed to program a server for deep learning. Because of the graphics driver on that server, there is really no option to run a gui application. So I had to learn vim. It turned out to be not that difficult to get used to it. The only complain I have is code navigation. The font size of the vim is fixed to the font size of the terminal. The text is relatively large, therefore the viewing window can only show few lines of code. Sometimes, I need to reference a previously defined variable or function of the same file, It's difficult to quickly navigate to the right place. With sublime text, it's mini map navigator is so convenient to allow me go back and forth between locations. With vim, however, I rely more on my memory. I need to go back once and remember everything, and then go to the end of the file to edit.

Phlogistique 10y ago
You might like the '*' and '#' keys, as well as marks, particularly "'.".

twblalock 10y ago

One of the nice things about being an Emacs user (hang in there, I have a real point about Vim to make) is that the concepts (especially non-modal editing) and the keyboard shortcuts map well to newer IDEs. I switch between IntelliJ and Emacs all day, and all I had to do to become comfortable is choose the Emacs keyboard preset in the IntelliJ preferences. The same is true for Eclipse and Visual Studio. The Emacs paradigm is a lot more similar to contemporary IDEs than the Vim paradigm, and that makes it a lot easier to switch back and forth. While a better Vim is a nice goal, I don't see how it will bridge the gap between Vim and newer editors/IDEs unless it includes some fairly fundamental changes to the Vim paradigm. But then it wouldn't be a better Vim -- it would be something different enough that Vim users probably wouldn't like it. I suspect that Vim and modern editors/IDEs are doomed to remain divergent forever.

SatvikBeri 10y ago
FWIW, I'm a 6-year Vim user, I have the same great experience using Jetbrains IDEs with the Vim presets.
QuadrupleA 10y ago
Just a quick note that I've been using Visual Studio and the VsVim plugin happily for years. They work great together. All the Vim-fu plus real keyword completion, jumping to definitions, instant renaming of any function/variable (VAX plugin) etc.
scaryclam 10y ago
I find that nearly all editors have VIM "mode" that will allow you to just use the vim key bindings, so it's not really a problem swapping between two editors. They tend to have an emacs mode as well, in case you're interested in using your emacs keys.
- brennen 10y ago
  Unfortunately, this is superficially true but not in practice all that helpful for a lot of us. Most vim-style input modes or plugins for other editors are woefully lacking, and even very good ones (evil mode) seem to differ enough to be uncomfortable for a subset of long-term vim users. Like: I've used Emacs extensively in the past, and certainly _could_ switch to evil if need be, but a few days of recent effort showed me that the switching costs are higher than I'm willing to pay right now, and it's not clear I'd be any better off in the end. Whatever the infelicities of vim's implementation (there are certainly plenty), I think there's a tendency to underestimate the expressive nuance and (for lack of better words) complex texture of the interface.

mponw 10y ago

I started a similar project in 2013, sadly never delivered a working prototype. Its name was going to be "Kuji Editor", basically an editor in visual mode by default and with context-verb grammar instead of vi's verb-object grammar. I knew this would represent a big improvement over other editors because of a more intuitive and modern approach leading to a better workflow. I started with building the UI in PyGame but never got further than that... (I am really disappointed I didn't spend more time on this now I see the attention Kakoune gets. I would have loved the feeling of contributing something truly innovative... well...). Congrats to Maxime!

farresito 10y ago

I was pleasantly surprised at how good it is. Definitely keeping an eye on it.

JepZ 10y ago

The 'd2tf' example is just wrong... after realizing I didn't hit the right 'f' I would just press '.' (not 'ud2tf')... I think I will stay with vim for now, also the discoverability could be better... Btw. mixing vim with tmux also solves the 'command line next to editor' problem.

Rainymood 10y ago

Interesting, as a long term Vim user I might try this out. Currently invested some time in Spacemacs and I don't want to jump around too much. It really needs a catchier name though. We have Vim. Spacemacs. Emacs. Kakoune sounds a bit foreign imho.

visarga 10y ago

Problem with all these hotkeys is discoverability and memory. In the end, I use just a few well known hotkeys. It's useless to define hundreds of them. I don't like modal editors especially because keys have even more functions then, which I have to remember.

tschellenbach 10y ago

Interesting, but how will they make money to fund continued development? So many editors show great promise to slowly disappear and fade away because of budget issues.

omtinez 10y ago

Shameless plug: I have been working on my own code editor as well, I wanted something between Notepad++ and Jupyter Notebooks; I called it TeIDE: https://github.com/omtinez/teide https://github.com/omtinez/teide Fully open source, built on Polymer and currently working on a plugin/action model to enable users to execute custom commands on the underlying shell. Accepting pull requests and all forms of feedback :-)

saosebastiao 10y ago

I love this idea, and look forward to trying it when I have a little more disposable time to learn something new. I just want to point out one thing: While it is admirable that this project sticks to just text editing, our text editors often form a part of a system. This includes IDEs, shells and interpreters, and the OS itself. One of the missing "modes" of vim is a yield-to-something-other-than-editor mode. Because we don't have this, any time I use vim or a vim compatibility layer, I end up having to remap keys from their defaults to something that I have trouble remembering and is completely different from the docs. I hate remapping keys. Give us a mode that allows us to keep the rest of our ecosystem intact.

kstenerud 10y ago

Blah blah blah another "modal editing is better" article. And once again, I'm not impressed. You may not like GUIs, but I do. You may think that keeping your hands on the keyboard and off the mouse makes you more productive, but I don't. We all have our preferences. Yours are not better than mine. End of story.

zem 10y ago
they're not mutually exclusive. vim's modal features are handy even if you use gvim - e.g. you could select a range of text with the mouse and use y to yank it because you were in editing rather than insert mode

gdmeteor 10y ago

I've actually never heard of Kakoune. And I'm not too familiar with verb based text editors in general. I've been using Visual Studio Code recently and like it functionality wise. http://jsdiaries.com/2016/11/27/visual-studio-code-features-part-1/ http://jsdiaries.com/2016/11/27/visual-studio-code-features-... I may move on to a verb based editor like this as my projects getting more complex and navigating through verb commands is a must. But can someone tell me what languages would benefit most from an editor like Kakoune? I'm assuming creating macros would be a big part of using it ?

nonsince 10y ago

This is awesome, I only wish it was a mode integrated into Emacs, like evil-mode. I can't afford to give up the debugging, completion etc. that I get as part of emacs, but I would love to use this in my day-to-day flow.

hugozap 10y ago

I moved from Sublime Text to vim. Tried emacs first but for some reason it didn't click. vim was much easier to start with and I see the benefits of mastering modal editing. It's not about typing faster, but developing the muscle memory to transform text without thinking about it. That's really powerful.

jonahrd 10y ago

A few questions after playing around with this for a bit: After making a complicated selection, doing something else, I want to go back to that selection easily. Is there a selection history? A way to execute the last selection? I tried running a shell command that waited on input and kak hung waiting for the command to finish. is there a way to kill the command? Or better, a way to interact with the command after its running? I like it so far!

0xFFFFFF 10y ago

I'm still waiting for someone to do a modal abstract syntax tree editor. You would only type text when naming something, the other mode would be for navigating the AST.

toxicFork 10y ago
Sounds like a visual scripting system with low level constructs.
- 0xFFFFFF 10y ago
  Visual scripting is nice in that you can have a seperate presentation layer on top of the language syntax. There's a lot of potential in improved readability that way I think. Most visual scripting depends on mouse actions, which is kind of slow and I suspect a big reason why programmers dislike it so much.
nrub 10y ago
Have you used paredit-mode in emacs with a lisp dialect? Getting proficient with this mode can be a lot like what you describe. Paredit let's you navigate and edit the tree structure of lisp code pretty effectively. It's not inherently a modal paradigm, but I used it evil-mode successfully. I'd imagine what you describe could be a refinement on that technique. Lisp lends itself well to this type of editing due to it's lack of syntax. Other languages are more difficult.

eridius 10y ago

This looks very interesting. But why does this whole site try to use WebM video even on browsers that don't support it? When viewing this site in Safari, there's a bunch of broken videos scattered around.

deft 10y ago

The features demostrated here are almost the exact ones I'm looking to do in Vim (I've only been using for a few months) and the way they describe them here makes them so simple. I hope this continues to mature!

asimjalis 10y ago

Neat. One question: How can I script it? What is the scripting language for customizing the editor? I couldn’t find information on this in the documentation.

wtetzner 10y ago
This thread explains that you script it using shell commands: https://news.ycombinator.com/item?id=13166635 https://news.ycombinator.com/item?id=13166635
- flukus 10y ago
  So it's not possible to have something like vims quickfix?

BrandoElFollito 10y ago

vi [vee-ay] : Aztec expression for "how the fuck do I get off this shit". Esc Esc : q!

exabrial 10y ago

I think editors provide at least two more things: Code completion and global refactoring. Eclipse/IntelliJ users in the Java world can pound out entire programs in seconds using nothing but keyboard shortcuts. Are there features like this for other languages?

dpc_pw 10y ago

I really like it. However given how confusing for my Vim muscle memory a switching would be, I would have to make sure the ecosystem around it is good enough. Basic programming languages highlights and completions and similar tools.

sushisource 10y ago

This might get lost in here, but one thing that I'm dissapointed by is I love this idea, it looks fantastic, and I'm a vim "user" that would love to switch. But I put user in quotes because really I use IntelliJ or VS or whatever, with the vim plugin, for the rich refactoring / autocomplete support which, for most languages, is awful to try to integrate with a command line editor like this. Anyone know if the author plans to make a plugin client? That would be amazing.

farresito 10y ago
The problem, I think, is on Intellij's or VS' side rather than on Kakoune's; otherwise, we would already have an Intellij client based on neovim. I'm in a similar boat to you, but I don't think there is much hope unless those IDEs actually do something to make this viable.
- sushisource 10y ago
  Yeah, you're probably right. I was sort of implying "with the understanding it's unlikely any of the IDE makers are going to do this, it would be nice to have the common code separate so a plugin wrapper is easy". Something along those lines.

voaie 10y ago

Finally, the legacy burden of vim and neovim gone, and a whole new world :D Thank you a lot!

FrancoDiaz 10y ago

I'm glad to see someone thinking outside of the vi box when it comes to modal editing. But the problem is that editors aren't very useful on their own without an ecosystem of development plugins. I'd love to see this ported to VSCode.

ferologics 10y ago

This reminds me of "vis" from about a year ago - https://github.com/martanne/vis https://github.com/martanne/vis

rgun 10y ago

How do you pronounce 'kakoune'? Some people are already using 'kak' instead of 'kakoune', IMO 'kak' will be a better name.

nedt 10y ago
Kak sounds like poo-poo in german and similar languages. It's even a loanword in english.

jerkstate 10y ago

I tried this editor out and the most maddening thing was figuring out how to reduce multiple cursors back down to one. I finally figured out - by accident - that pressing the space bar reduces your number of cursors down to one. The documentation needs to make this basic, necessary key-command a lot more obvious.

etruong42 10y ago

I see many valuable feature, such as the highlighting and the tooltips. I wonder if these could have been expediently implemented as VIM plugins - perhaps each feature could have been a VIM plugin so that people can pick and choose which feature set they wanted.

iplog 10y ago

Really interesting project and looking forward to having time to play a bit more with it. After trying it for the first time and reading the documentation I have the impression that the `alt` key is used a lot as a modifier key for basic things such as selecting inner objects. One thing I love about Vi and Vim is that most it tries to reduce the usage of modifier keys which is awesome when you are touch typing. I would love to know why the author chose the `alt` key and what the other options were. That's a great project and I'm sure it could help a lot of developers to understand modal mode. Great work!

nikolay 10y ago

Why not write it in Rust though like Google's Xi [0]? [0]: https://github.com/google/xi-editor https://github.com/google/xi-editor

steveklabnik 10y ago
> I have been working, for the last 5 years, Rust was very, very different five years ago.
- nikolay 10y ago
  Sorry, I've missed that!

bsg75 10y ago

Boost dependency, which I always have bad luck getting to build in a reasonable time. Isn't Boost going away?