
Why Kakoune – The quest for a better code editor - tosh
http://kakoune.org/why-kakoune/why-kakoune.html
======
gmueckl
Every time I see a new text editor announced for programming, I find that is
just a rehash pf unstructured text editing functionality. Programming
languages are heavily structured, and code transformations between text and
syntax tree forms have been implememted numerous times. So why the focus on
editing plain text instead of trying to create an editor that actually
transforms the syntax tree directly? I don't know what the UI would look like,
but an editor that is based on refactoring operations instead of direct text
manipulation might end up being a very powerful tool.

~~~
Rusky
Structural editors are great, and normal text-based programming editors should
probably support the same kinds of transforms, both precisely and fuzzily.

But a typical editing session will go through a lot of "invalid" states _by
design_. Trying to enforce that structure is preserved at all times is a
hindrance in many scenarios.

And further, if you bake structure into your editor in that way, it's much
harder for anyone to invent new structures. Having good tools for unstructured
text editing is valuable as, if nothing else, a fallback for when your
structured editor doesn't understand the language you're editing.

~~~
gmueckl
Invalid states should only need exist in terms of virtual placeholders for
elements required by the grammar, but not filled in by the user. I have a
(unsupported) suspicion that directly editing a syntax tree when gaps in its
structure ate allowed is no more cumbersome than editing the textual
representation.

My understanding is that tools like Eclipse and Resharper work on pretty
similar models internally to prevent complete failure to understand a code
file while it is being mangled by the user.

~~~
Rusky
Yes, but that requires a lot of language-specific work and heuristics to make
work, and there are still a lot of places where the approach falls down.
(Source: I work on precisely that sort of tool for C++.)

So you need the text-based fallback here, and you still need it anyway for the
case of editing something a structure the editor doesn't know.

~~~
gmueckl
C++ is the worst possible language in this case. Its complexity is immense and
the C preprocessor layered on top makes a straight mapping between code and
syntax tree impossible to achieve in general. Simpler languages like Java or
C# (at least relative to C++) allow such syntax tree based tools to reach
much, much further. I do believe that it should be possible to build an editor
for "nice" languages of that kind that is entirely based on editing the syntax
tree.

------
nmca
All the biggest gains I've seen in editors are, in order of importance, inline
doc lookups, easy local file search with file-customisable ignores, quick file
opening with fuzzy search and Emmet abbreviations.

Does anyone know how Kakoune does in terms of these features? They're all much
more important to me than say, syntax highlighting, which I find neither here
nor there.

~~~
adrusi
Kakoune doesn't come with any of these built in, however kak-lsp [1], the
language server protocol client implementation, is fairly mature, and I
wouldn't be surprised if it supported inline doc lookups. Certainly kakoune
provides the facilities needed to implement that.

Cross-file grepping, and fancy fuzzy finders are considered beyond the scope
of the editor, but the wiki has some tips for integrating a separate fuzzy
finder program into kakoune [2].

Emmet would be super easy to implement but it just hasn't been yet to my
knowledge.

[1] [https://github.com/ul/kak-lsp](https://github.com/ul/kak-lsp)

[2] [https://github.com/mawww/kakoune/wiki/Fuzzy-
finder](https://github.com/mawww/kakoune/wiki/Fuzzy-finder)

------
icholy
I really like Kakoune and its ideas. But I've invested too much into vim to
switch at this point :(

~~~
wodenokoto
I have yet to "invest" in a terminal editor, so but I feel like it is
impossible to choose.

They all have a steep learning curve and it seems like you need to climb
pretty far up that curve before you can even judge if it is worth it to begin
with.

~~~
jgtrosh
It _is_ worth it, though not necessarily for improving the things you care
about now.

------
jchw
I tried this editor a while ago and immediately was able to understand their
model for modal editing. Once you've gotten it, it's hard to not wish vim
worked this way.

The problem is, vim is everywhere, and Kakoune isn't. :(

~~~
petepete
This is also my problem. Additionally I couldn't work out how to create
language-specific rules in the config (tab width, spaces, indenting etc).

I want to switch but need to make the process a bit smoother.

------
cosmojg
I'm so excited about Kakoune! I hope it manages to achieve critical mass along
with a booming plug-in ecosystem. As it is, things are pretty lonely.

------
tincholio
I've just played a bit with it, and it looks really good. What would rock is
an Evil-like implementation on top of Emacs...

~~~
TeMPOraL
I recall someone in /r/Emacs pointing out that Emacs keybindings already
implement Kakoune's "object then verb" philosophy. For instance, to delete
text from current position until next occurrence of a letter z, you'd do C-SPC
C-s z RET C-w [0]. C-SPC C-s z RET is the object part (C-SPC - start selection
(but see [0]), C-s - start incremental search, z - find next z, RET - confirm
you found what you were looking for). C-w is the verb part - cut region. If
you want to cut until the n-th occurrence of z, just press C-s a few times
after entering z.

\--

[0] - C-s z RET C-w, if you're not using transient-mark-mode, aka. a visually
marked, explicit selection common to most editors. With transient-mark-mode
disabled, there is always a region between mark and point, and after accepting
a search with RET, C-s drops a mark at the place you were when you started the
search. transient-mark-mode is active by default (probably to reduce learning
curve); working without it is weird at first, but also rewarding in terms of
efficiency.

~~~
xrd
Thank you for this!

------
dghf
> Because of the verb followed by object grammar, vi changes are made in the
> dark, we dont see their effect until the whole editing sentence is finished.
> dtf will delete to next f, if you then realize that was one f before the one
> you targeted, you need to undo, go back to your initial position, and try
> again with d2tf.

Or just do . (full stop/period), which will repeat the last command, and in
this case delete to the f you want.

~~~
exDM69
Repeat will only fix this particular case. If you did "dtf" and wanted "dff",
repetition won't help.

Kakoune is kinda like vim in visual mode (or block visual) with multiple
cursors.

~~~
dghf
> Repeat will only fix this particular case. If you did "dtf" and wanted
> "dff", repetition won't help.

My point wasn't that repetition is a panacea, but that the example in the
article isn't a good one.

------
ksec
Off Topic: None of the Video works on the site works in Safari as they are all
webm.

~~~
pedalpete
I don't think it's a webm thing, they're broken for me in Chrome and FF as
well.

------
SeriousM
I can't find any information about the keyboard issues vim has with eg. German
layout. Does this editor suffers the same problems?

~~~
xashor
As kak has roughly the same key bindings as vim, if you found vim unbearable,
you'll have problems with kak, too. However, I'm not sure what issues you
think of, I've used vim/kak with a qwertz layout without problems. Just re-
assign äöü.

------
xrd
Is there anything here for emacs users? ;) This is really an interesting
thread.

------
zan
I love the ASCII arty Clippy for tool tips!

------
nasredin
Not for Windows.

"Modal editor · Faster as in less keystrokes · Multiple selections ·
Orthogonal design"

I love it when software developers assume everybody else knows what their
software runs on. SMH.

~~~
vultour
The examples are obviously in a terminal so you should expect it to not work
on Windows.

~~~
kungtotte
There are lots of screenshots of vim running in a terminal and yet it works
fine on Windows.

