
Why Kakoune – The quest for a better code editor - petepete
http://kakoune.org/why-kakoune/why-kakoune.html
======
greenspot
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.

~~~
wangchow
In this age we need to think about things like voice control and 3D
manipulation of data-structures and a dynamic view of the code.

We can truthfully keep designing 2D editors (and we will always most likely
use them to some extent) but I believe it is more important to consider
different UI paradigms altogether.

For instance, what about editing a living code environment? Game development
is very immersive: you can manipulate a running environment and see results
immediately. How can this be extended to other development tasks like server-
side development?

What if, when you select a for loop from code fragment a 3D visualization of
the programs data structures at that point is shown to the user. What if you
can, instead of launching a debugger, run the debugger as you're writing the
code and step forward and back and see these visualizations change?

We have all the technology. It's time to get to the next level.

~~~
mncharity
Yes, but. Keep ripeness in mind. It's very easy to spend effort in this area
"too soon". So shape projects with care.

I run a Vive on linux. Which required my own stack. Which took excessive time,
and is limiting, but has some road-less-traveled benefit of altered
constraints. So I've gone to talks, and done dev, wearing Vive with video
passthrough-AR, with emacs and RDP, driven by an old laptop's integrated
graphics. Yay. But think 1980's green CRT (on pentile, green is higher res).
In retrospect, it was a sunk-cost project-management garden path.

There's been a lot of that. One theme of the last few years, has been people
putting a lot of effort and creativity into solutions to VR tech constraints,
only to have the constraints disappear on a time scale that has them wishing
they had just waited, and used the time to work on something else. It's fine
for patent trolls (do something useless to plunder future value), and somewhat
ok for academics (create interesting toy), but otherwise a cause for caution.

So on the one hand, I suggest that if the center tenth of VR displays had
twice their current resolution, everything else being current tech, we would
already be starting on a "I can have so many screens! And they're 3D! And..."
disruption in software development tooling. But that's still a year or two
out. Pessimistically, perhaps even more, if VR market growth is slow.

In the mean time, what? Anything where the UI isn't the only bottleneck (work
on the others). Or which can work in 2D, or in 3D-on-2D screen (prototype on
multiple screens). Or is VR, but is resolution insensitive, and doesn't
require a lot of "if I had waited 6 months, I wouldn't have had to roll my
own" infrastructure. Or which sets you up interestingly for the transition
(picture kite.com, not as a 2D sidebar, but generating part of your 3D
environment). Or which can be interestingly demo spiked (for fun mostly?).

For example, I would love to be working on VR visual programming on top of a
category theoretic type system. But there seems no part of that which isn't
best left at least another year to ripen. Though maybe 2D interactive string
diagrams might be a fun spike.

~~~
wangchow
Very well put. I have to agree that these technologies are still blooming and
there are uncertainties--especially in my mind with cost associated with
buying devices. Hololense for example with a $3000.00 USD developer edition
isn't exactly accessible to the general community! The next 10 years however
will probably be pretty exciting in the AR/VR space.

What about voice-controlled programming though? I always thought it would be
nice to voice-control my OS. Not specifically for a text-editor, but as a
general interface to the OS. It would be nice to move these features out of
the cloud and directly onto systems. But then again, a lot of companies
(amazon, microsoft, apple) probably don't want to encourage reverse-
engineering of their intellectual property. We definitely need open-source
variants.

Better AI chips with lower power-consumption and optimization for these types
of operations will hopefully usher in a new set of productivity-enhancing
applications!

------
ncd
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?

~~~
notheguyouthink
I know you're seeing a ton of "yes it's worth it" posts, but i just wanted to
add a slightly different perspective. Yes, it's worth it even when you aren't
an expert at Vim.

I am constantly learning new Vim commands[1], and i feel i only know a tiny
fraction of the vim editing language. Yet, i still love vim, and use it
constantly, for everything.

The approach i take, as to make it enjoyable and not a job, is: "is what i am
doing now annoying?". If you find yourself hitting j _(to move down)_ 40 times
in a row, or holding it to move down slowly, etc - Google for a solution[2].
It can be a little annoying in the beginning, but when you're starting out
your far less likely to want to "fix" every bad pattern, and therefor you
aren't spending all your time Googling. In my experience, you are only
improving upon the things that most annoy you, and as time goes on, you
improve quite a bit while not even trying.

[1]: discoverability is not it's strong suite, which is why i'm going to try
Kakoune. [2]: You can multiply the command (40j), or <Ctrl-f>/<Ctrl-b> to
jump. Among other things.

~~~
Shorel
Not much better. You have to count to find out that 40 number.

Sometimes a mouse is faster.

~~~
thatmiddleway
You can set line numbers in vim to be relative, then there's no counting
involved.

------
twblalock
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.

~~~
scaryclam
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
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.

~~~
WhatIsDukkha
I've been using vim for decades and use evil/emacs now.

It's simply not true that the vim modes outside of vim are critically lacking.

In fact almost all of them support text objects and the other key parts of the
vim editing experience that we are talking about here and they do it well.

Some things like macros or perfect register support are not there (evil is
pretty great though) but they generally have useful analogs.

This is across multiple IDE emulations that I've used.

What you said might have been true 6-7 years ago but is not true now.

~~~
flukus
It's still true, most won't even allow you to remap keys or work with the
system clipboard like you can in vim. Nevermind things like proper scripting
and window support.

------
cwp
> 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
Quicksilver, still? Why not move on to Alfred?

~~~
egypturnash
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
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
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.

~~~
eridius
Alfred does use that structure, and as far as I remember, it always has. I can
indeed do <file>, <email to>, <person> in Alfred (though my most common
object, verb, indirect object sequence is <file>, <open in>, <app>).

------
reitanqild
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.

~~~
notheguyouthink
> That said I suspect most people would be better off learning a good IDE
> properly, including but not limited to:

To be clear, do you think a "good IDE" is inherently better than Vim/Kako for
most people?

Personally i don't see a difference in a GUI based editor and a text based
editor. In fact, i quite prefer text based, because it forces an editor to
treat the keyboard as a first class citizen - GUI IDEs can get lazy and revert
to mouse whenever they please.

I can see the argument that Vim might not be inherently as good as a "good"
GUI editor, but i don't think that is a negative towards the potential of text
based editors. It just means that we need new editors to focus on the UX, imo.

With that said, i'll be quite glad that we're moving towards standardizing
_(of sorts)_ a code editor protocol so that new editors don't suffer from lack
of tooling. It will be great to see a single set of tooling _(formatting,
linting, imports, syntax checking, etc)_ plug into any new editor that might
pop up.

Switching editors has enough friction, tooling shouldn't be one.

~~~
marktangotango
The core "IDE" features you don't normally get with an editor are things like
project views, intellisense, code completion as you type, real time parsing
and error highlight, code navigation. Sure you can get most all of this by
wrangling plugins for vim (or which ever editor you choose) but in an IDE like
eclipse, netbeans, intellij, visual studio, it's all there, ready to go.

In effect, a modern IDE is "programming ability" multiplier. It helps me code
smarter and faster. That plus understanding what's going on behind the scenes
is a powerful combination.

~~~
wtetzner
Sure, but the biggest problem with modern IDE's is the fact that they are
terrible at editing text.

IDE's and text editors overlap in their uses, but they are not the same.
Sometimes you really do just have a text editing task, and none of the IDE
functionality will help with it. Also, the ways in which IDE's are extensible
is lacking compared to something like Emacs. Yes, they come with a bunch of
built-in useful stuff, but sometimes you want to add a keybinding to do some
editing task you do a lot in a particular project or company, even if it's not
useful in a more general-purpose setting.

~~~
reitanqild
_Yes, they come with a bunch of built-in useful stuff, but sometimes you want
to add a keybinding to do some editing task you do a lot in a particular
project or company, even if it 's not useful in a more general-purpose
setting._

Don't know what IDE you used but Netbeans is _very_ customisable and
extensible.

I think this is true for IntelliJ and eclipse as well and it would surprise me
if it wasn't for Visual Studio.

(In fact I think I have seen vim modes for all of these and even embedded vim
in eclipse.)

~~~
wtetzner
I think I probably didn't explain my meaning well. For Netbeans, Intellij,
Eclipse, VS, etc. you tend to have to create a new project to write a plugin.

In Emacs, adding a simple extension is simply a matter of adding a function to
your .emacs file. So adding useful functionality is very low friction, low
enough that you can afford to do it when it wouldn't be worth the effort in an
IDE.

------
omtose
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.

------
SeanDav
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
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
What exactly isn't pretty about vim (specifically gVim) on Windows?

~~~
nameless912
The default fonts, the menus, the menu icons, the font rendering, the
inability to use many plugins....

------
hans
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.

~~~
blakeyrat
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.)

~~~
spc476
To prod back, you have three source code files---one is in Word Perfect format
from 1987. The second is from Microsoft Word from 1998. The third is an ASCII
text file from 1972. Which one can you open and reuse _today_?

~~~
blakeyrat
I can open all of those formats in Microsoft Word right now this instant. So.

Good argument?

~~~
spc476
No. How about Easy Writer II? Or even Type-Rite?

------
IshKebab
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
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.

~~~
optimuspaul
I find that console apps are far less intuitive when it comes to visual
thinkers. I also am not too keen on modal editing, it doesn't match how I do
most things in life. I don't have to switch out my teeth when eating vs
drinking. It just doesn't seem natural to me. I've always found I'm more
productive with a GUI. Command line is great for simple tasks and executing
commands, but editing files has always seemed less than ideal. You have to
remember so many key combinations and commands and track what mode you are in
and what modes are available. I would rather spend that brain power on solving
problems.

~~~
falcolas
> I don't have to switch out my teeth when eating vs drinking.

But you do switch how your mouth is working when switching between eating and
drinking. In one, you masticate and move food around your mouth before
swallowing once (maybe twice), whereas the other involves directing fluids
back to your throat which acts in a near-continuous swallowing action.

> You have to remember so many key combinations and commands

They become muscle memory after an admittedly non-trivial amount of use. Yes,
it is an investment in your future usage of that tool.

And to be fair, you had to memorize C-x, C-c, and C-v at one point too.

~~~
oblio
He doesn't control his mouth when switching between eating and breathing, I'm
pretty sure that it's part of the autonomic system. You kind of made his point
since there's no way Vim actions actually become fully reflex actions,
especially the powerful stuff that separates Vim from a good IDE, since the
vast majority of those really complex actions will be done at best dozens of
times per day (and I'm being generous here).

~~~
abeyer
> there's no way Vim actions actually become fully reflex actions

You might be surprised. Maybe not quite the level of a true "reflex", but it
can get close. I find I not infrequently get weird compile/test/spellcheck
errors when I'm not using vim and go back to find a string of vi keystrokes in
the middle of my document that I typed without consciously realizing.

------
JadeNB
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.

------
keepper
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
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
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
Could be `kk`

~~~
Kareeeeem
And that is short for cancer in Dutch, used as a swear word.

------
0xFFFFFF
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
Sounds like a visual scripting system with low level constructs.

~~~
0xFFFFFF
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.

------
diggan
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
You can find the editor source, and installation instructions on github:
[https://github.com/mawww/kakoune](https://github.com/mawww/kakoune)

~~~
diggan
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
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.

------
geodel
A few things I like:

* No NodeJS/NPM * No Electron * No multi-threading

~~~
buster
No multi threading is a plus?

~~~
geodel
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
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.

------
nerdponx
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
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.ka...](https://github.com/mawww/kakoune/blob/master/rc/core/grep.kak)

[2]
[https://github.com/mawww/kakoune/blob/master/doc/json_ui.asc...](https://github.com/mawww/kakoune/blob/master/doc/json_ui.asciidoc)

~~~
notheguyouthink
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
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)

~~~
notheguyouthink
Yea i'm definitely going to try this out. Thanks!

------
equalarrow
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.

~~~
akkartik
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))

------
dri_ft
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.

------
saosebastiao
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.

------
eridius
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.

------
DigitalJack
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
"Clippy's Revenge" sounds like a cool name, at least it's more memorable than
Kakoune.

------
kkotak
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.

~~~
Cpoll
This sounds like macros? Of course, the problem with macros is that you
sometimes realize you should have hit "Record" only after you've completed the
action.

~~~
JohnDotAwesome
> the problem with macros is that you sometimes realize you should have hit
> "Record" only after you've completed the action.

Happens to me all the time. But if using a macro was actually worth the effort
in the first place, then it's probably still worth the effort to undo and
record

~~~
notheguyouthink
Definitely. In fact because of that "blind actions" that Vim has, and Kakoune
seems to be trying to fix, i often record macros multiple times. I'll make the
macro, but the realize it doesn't fit all cases i wanted it to.

------
vanderZwan
> _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?

------
asimjalis
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
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
So it's not possible to have something like vims quickfix?

------
jonahrd
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!

------
JepZ
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.

------
billconan
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
You might like the '*' and '#' keys, as well as marks, particularly "'.".

------
visarga
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.

------
mponw
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!

------
iplog
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!

------
nonsince
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.

------
nikolay
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
> I have been working, for the last 5 years,

Rust was very, very different five years ago.

~~~
nikolay
Sorry, I've missed that!

------
sushisource
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
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
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.

------
omtinez
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 :-)

------
tschellenbach
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.

------
aamederen
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
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.

------
hugozap
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.

------
jerkstate
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.

------
exabrial
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?

------
etruong42
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.

------
Rainymood
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.

------
dpc_pw
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.

------
chrismorgan
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
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.

------
deft
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!

------
eptcyka
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.

------
andrewfromx
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.

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

------
ferologics
This reminds me of "vis" from about a year ago -
[https://github.com/martanne/vis](https://github.com/martanne/vis)

------
rgun
How do you pronounce 'kakoune'?

Some people are already using 'kak' instead of 'kakoune', IMO 'kak' will be a
better name.

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

------
msl09
The videos don't seem to play on firefox 45.5.1

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

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

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

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

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

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

~~~
mawww
The font is called terminus

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

Esc Esc : q!

------
gdmeteor
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-...](http://jsdiaries.com/2016/11/27/visual-studio-code-features-
part-1/)

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 ?

------
kahrkunne
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?

------
FrancoDiaz
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.

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

------
kstenerud
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
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

