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

Kakoune – An experiment for a better code editor

kakoune.org

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Kakoune – An experiment for a better code editor

#21

Post by mawww »

Direct wrote: post #8

I tried switching to this editor permanently from vim. The selection based movements are asurdly good, I could kill for something like this in vim. However I couldn't stick with it for two reasons. The first is when I went to figure out how to customise it, I found that the customisation is essentially vim like but weaker. Everything is hardcoded like it would be in vim but with less options. If you're used to Emacs…

Hello,

Glad to hear you liked the interaction model, may I ask you what kind of options were missing for you ?

The extension model is, I agree, unorthodox, but I think it does work reasonably well (the file you linked manage to provide asynchrounous clang completion and syntastic like diagnostics using it), and keeps things simple. Note that we try really hard only to depends on POSIX tools, so the scripts are actually targeting POSIX shell.

The rational behind this extension model can be found there: https://github.com/mawww/kakoune/blob/master/doc/design.asci...

And a more in depth explanation on how to use it is there: https://github.com/mawww/kakoune/blob/master/doc/interfacing...

Re: Kakoune – An experiment for a better code editor

#22

Post by mawww »

chc4 wrote: post #7

I've played with Kakoune a little bit not that long ago. It's actually pretty nice. By far the best feature is the popup that lists all the sub-actions for chords: imagine if, when you press "g" in Vim, it lists all keys you press after AND what they do. It makes it very easy to figure out new behavior. The idea of working on selections is also very intuitive and works well, both in vim compatability and ease of use.…

Hello,

Very interested to know what was missing for you ? We do not have options for everything, but I'll gladly add more options if there is a reasonable use case for them. In other words, options only get added if someone requests them (and makes a good case for them).

scripting support is documented in: https://github.com/mawww/kakoune/blob/master/doc/interfacing...

Re: Kakoune – An experiment for a better code editor

#23

Post by oakhaven »

drewm1980 wrote: post #18
chc4 wrote: post #7

I've played with Kakoune a little bit not that long ago. It's actually pretty nice. By far the best feature is the popup that lists all the sub-actions for chords: imagine if, when you press "g" in Vim, it lists all keys you press after AND what they do. It makes it very easy to figure out new behavior. The idea of working on selections is also very intuitive and works well, both in vim compatability and ease of use.…

well intentioned nit-pick: vim commands starting with a g are NOT chords, and that's very important from am usability standpoint. For the most part vim avoids chords, while E-macs embraces them. It's a question of whether you want to strain your hands (chords/emacs) or your brain (modal/vim) for triggering infrequent commands.

the last sentence is a good point! I am not very precise typer, and I use vim.

I work on different keyboards, actually 3 different layouts: external keyboard home and at work, home laptop, and work laptop (different one).

I think it would be difficult to do the emacs chords on different layouts. For basic vim usage I just need to adapt to 2 special keys - colon and slash (+ right shift). That takes just few minutes.

Re: Kakoune – An experiment for a better code editor

#24

Post by Direct »

mawww wrote: post #21
Direct wrote: post #8

I tried switching to this editor permanently from vim. The selection based movements are asurdly good, I could kill for something like this in vim. However I couldn't stick with it for two reasons. The first is when I went to figure out how to customise it, I found that the customisation is essentially vim like but weaker. Everything is hardcoded like it would be in vim but with less options. If you're used to Emacs…

Hello, Glad to hear you liked the interaction model, may I ask you what kind of options were missing for you ? The extension model is, I agree, unorthodox, but I think it does work reasonably well (the file you linked manage to provide asynchrounous clang completion and syntastic like diagnostics using it), and keeps things simple. Note that we try really hard only to depends on POSIX tools, so the scripts are actual…

Honestly it's been a little while, I can't remember. However this is more or less why I went back to vim. Your other comment in particular:

> We do not have options for everything, but I'll gladly add more options if there is a reasonable use case for them. In other words, options only get added if someone requests them (and makes a good case for them).

I don't really want to switch to an editor where missing options might have to be justified. I'm not knocking your work, it's really good, and my complaint applies to vim as well. But if I can't implement something myself as an add-on (which I definitely have more power to do in vim) and have to wait for it to be patched and released in your release cycle I'd rather just try and implement your features in vim and keep the customisability.

Having said that I could be wrong and maybe the plugin system is more powerful than I thought. But as an example, I have a 5 line function letting me have ctrl-p like functionality backed by fzf in vim. I can't figure out how I would do that in kakoune at all.

Re: Kakoune – An experiment for a better code editor

#25

Post by mawww »

Direct wrote: post #24
mawww wrote: post #21

Earlier quoted context omitted.

Hello, Glad to hear you liked the interaction model, may I ask you what kind of options were missing for you ? The extension model is, I agree, unorthodox, but I think it does work reasonably well (the file you linked manage to provide asynchrounous clang completion and syntastic like diagnostics using it), and keeps things simple. Note that we try really hard only to depends on POSIX tools, so the scripts are actual…

Honestly it's been a little while, I can't remember. However this is more or less why I went back to vim. Your other comment in particular: > We do not have options for everything, but I'll gladly add more options if there is a reasonable use case for them. In other words, options only get added if someone requests them (and makes a good case for them). I don't really want to switch to an editor where missing options…

Thanks a lot for you reply, I try to be reactive to feature requests, especially easy ones like making something configurable through an option (I expect most of these to be resolved in a day or so).

Some people are using kakoune with fzf, using tmux to open a split, which is very simple to implement with fzf-tmux. Interacting with Kakoune interface ought to be possible but possibly more tricky.

Re: Kakoune – An experiment for a better code editor

#26

Post by Direct »

mawww wrote: post #25
Direct wrote: post #24

Earlier quoted context omitted.

Honestly it's been a little while, I can't remember. However this is more or less why I went back to vim. Your other comment in particular: > We do not have options for everything, but I'll gladly add more options if there is a reasonable use case for them. In other words, options only get added if someone requests them (and makes a good case for them). I don't really want to switch to an editor where missing options…

Thanks a lot for you reply, I try to be reactive to feature requests, especially easy ones like making something configurable through an option (I expect most of these to be resolved in a day or so). Some people are using kakoune with fzf, using tmux to open a split, which is very simple to implement with fzf-tmux. Interacting with Kakoune interface ought to be possible but possibly more tricky.

Yeah, I can't see how I would do it. I could open a tmux pane with fzf and run another kak window but that's not really the goal. I'd like to use fzf to open a found file in the current kak window. The plugin architecture just really limits this kind of thing, and this fzf example was just a simple one I wanted to use to demonstrate the point.

But again, the stuff you have in this editor is absolutely fantastic, really, I can't say that enough. I just personally find kak less flexible than an already inflexible vim so I couldn't stay with it.

If you have a way to do the fzf example though I'd be curious to see how you do it.

Re: Kakoune – An experiment for a better code editor

#28

Post by h2077545 »

Kakoune seems great and I hope I will eventually make the switch from vim but there are currently 3 things holding me back.

1. Slime-like interaction: In vim I'm used to [vim-slime](https://github.com/jpalardy/vim-slime) for interactive languages such as python but I couldn't yet find an equivalent way to do it in kakoune. I suspect there is an easy way to do something like this using `:new` or the tmux integration but I don't know how.

2. Executing commands in the underlying shell: With C/C++ I usually need to work only with a single file and a fast compile-run cycle. I have simple functions defined for compile and run in my vimrc so that I can do it with a simple key map but I'm not sure how to do this in kakoune. The problem is sometimes output of my program exceeds one line so `:echo` is not quite useful here.

3. ctags/cscope integration: I haven't really checked this yet but I need something for jumping around in large codebases.

Re: Kakoune – An experiment for a better code editor

#29

Post by 314 »

drewm1980 wrote: post #18
chc4 wrote: post #7

I've played with Kakoune a little bit not that long ago. It's actually pretty nice. By far the best feature is the popup that lists all the sub-actions for chords: imagine if, when you press "g" in Vim, it lists all keys you press after AND what they do. It makes it very easy to figure out new behavior. The idea of working on selections is also very intuitive and works well, both in vim compatability and ease of use.…

well intentioned nit-pick: vim commands starting with a g are NOT chords, and that's very important from am usability standpoint. For the most part vim avoids chords, while E-macs embraces them. It's a question of whether you want to strain your hands (chords/emacs) or your brain (modal/vim) for triggering infrequent commands.

I would like to see an option for both in a text-editor - they are not as far apart as people assume. In emacs there are not enough chorded options for everything so after a while they switched to dead-key like operations. That is basically a modal interface where you have to keep the mode key depressed.

My dream editor would feature: * Three modes: insert, quick commands, a searchable palette for everything. * Configurable switch between modal/non-modal use of the command key. * On screen display for quick command mode (e.g. a partially translucent display of the keyboard when command mode is entered with icons to show what each key does).

The memorability issue for key-strokes doesn't really exist in a modern desktop environment. It is a relic of terminals with low bandwidth and poor support for multiplexing information. In a windowed / eye-candied environment the memorability of shortcuts should be a non-issue and discoverability of the command-set should be improved.

At this point I have to accept that I've said way too much in response to your nitpick and I will stop typing now :)

Re: Kakoune – An experiment for a better code editor

#30

Post by RadioactiveMan »

delish wrote: post #14
pkkp wrote: post #2

You'll want to take a look at your site's theme on mobile devices. On my iPhone 6 on iOS 9 (Safari), the navigation bar is fixed at the top half of the pane and takes up over half the screen.

Same here. Here's a picture. https://twitter.com/zlrth/status/660671388693323777 iPhone 5s, iOS 9.1. sorry to all reading my tweet about the snark. But I just find it so sad that I have so much rendering power on desktop (JavaScript on/off, elinks web browser, my rss reader), but if some silly CSS thing borks the mobile page, there's nothing I can do.

I came here to include a picture of the kakoune.org problem, but since you already have one I'll include a (hilariously?) similar picture of your tweet.

http://i.imgur.com/zUYt7V9.jpg

On the subject of kak, I tried it a few months ago and thought it was really impressed by it but didn't stick with it long enough to decide if it would be better than vim for me.

Post reply on HN