Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Kakoune – The quest for a better code editor

kakoune.org

Post reply on HN
Print view View original

31–40 of 329 posts

Re: Why Kakoune – The quest for a better code editor

#31

Post by notheguyouthink »

omtose wrote: post #21
nerdponx wrote: post #7

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?

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] h…

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.

Re: Why Kakoune – The quest for a better code editor

#32

Post by OskarS »

laurent123456 wrote: post #20
greenspot wrote: post #18

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 ver…

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.

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.

Re: Why Kakoune – The quest for a better code editor

#33

Post by omtose »

notheguyouthink wrote: post #31
omtose wrote: post #21

Earlier quoted context omitted.

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] h…

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.

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

Re: Why Kakoune – The quest for a better code editor

#35

Post by omtose »

OskarS wrote: post #32
laurent123456 wrote: post #20

Earlier quoted context omitted.

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.

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 ca…

>How would that work if the motion comes first? Would I go "wwwwd"? Would that delete one word, or four?

'w' will move the current selection to the next word so only one word. To extend the selection you need to press 'W' so "wWWWd" will delete four words. For most motions (if not all), the uppercase variant will extend the current selection.

This also makes searching slightly different:

  / search forwards 
  ? extend selection forward
   search backwards
   extend selection backwards

Re: Why Kakoune – The quest for a better code editor

#36

Post by notheguyouthink »

omtose wrote: post #33
notheguyouthink wrote: post #31

Earlier quoted context omitted.

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.

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…

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

Re: Why Kakoune – The quest for a better code editor

#37

Post by athenot »

kilian wrote: post #17
keepper wrote: post #11

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 :-/

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 m…

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.

Re: Why Kakoune – The quest for a better code editor

#39

Post by sevensor »

laurent123456 wrote: post #20
greenspot wrote: post #18

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 ver…

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.

I often use visual selection mode in vim so that I can see what I'm about to operate on. For instance, if I want to change text between the cursor and the next match of a regex, I want to see the selection before I change it. So instead of c/re[enter], I type v/re[enter]c. It's one extra character, but it saves me a lot of headaches. This is the first I've heard of Kakoune, but I'm definitely intrigued.

Re: Why Kakoune – The quest for a better code editor

#40

Post by 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.

Post reply on HN