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

Kakoune Code Editor

kakoune.org

Post reply on HN
Print view View original

171–176 of 176 posts

Re: Kakoune Code Editor

#171

Post by TeddyDD »

FreeFull wrote: post #159
reegnz wrote: post #145

Earlier quoted context omitted.

You don't need multi-cursor selection in vim. Vim has all the tools necessary to achieve the same end result with the same convenience. [0] Just thinking about what crazy things I've done with macros that multi-cursor would be incapable of handling makes me chuckle. vim doesn't need the fancy features of other editors (except for maybe LSP and tree-sitter for a more IDE-like experience). The core problem is that you…

Judging by https://github.com/mawww/golf kakoune is capable of completing the majority of the same editing tasks as vim in a very similar amount of keystrokes. The main advantage of multiple selections is that you can see which text you will operate on ahead of time, rather than having to first select which operation you want (delete/yank/change/etc) and then which text it will affect. I think pointing out that vim's…

80 Better 18 Same 35 Worse

Golfing is not the best representation of day to day text editing, but I must say that optimal Kakoune solutions are usually pretty close to normal workflow.

Re: Kakoune Code Editor

#172

Post by pasabagi »

sidkshatriya wrote: post #111
HKH2 wrote: post #110

Earlier quoted context omitted.

How did you get Kakoune to segfault?

Kakoune is built in C++. So bugs will sometimes manifest as segfaults. You could be doing some normal editing, press a sequence of editing commands that might trigger some code that may subtly wrong. Sometime later, when C++ code tries to write to memory that it shouldn't have, you will segfault. In that respect this is true for any C/C++ application. Kakoune keeps fixing these issues as they come up.

You can segfault in rust, too:

  fn totally_safe() -> i32 {
    unsafe { *std::ptr::null() }
  }
This commonly happens if the person who wrote 'totally safe' thinks what they're doing is fine, and it actually isn't.

Re: Kakoune Code Editor

#173

Post by mikojan »

filoeleven wrote: post #169
chongli wrote: post #68

Earlier quoted context omitted.

I disagree that the editing model is better than vim. It’s fancier and makes for flashier demos but I don’t think it’s better. For one thing, it places the emphasis on editing in the large . That is, its default operating mode is to leave multiple cursors all over the buffer when you’re trying to jump around your file. You have to build a habit of pressing an extra key to dismiss the multiple cursors so you don’t ina…

When I last looked at Kakoune, it struck me as “Vim with training wheels,” in the best sense of the term. In other words, it has (all of?) vim’s keyboard commands, but with more visual feedback to show what they are doing live. I envisioned myself learning with Kakoune and eventually migrating to vim once they became ingrained. Or, at the very least, becoming proficient in vim so that I could use it more confidently…

I don't believe that'd help.

Editing in Kakoune encourages and enforces a different editing style (one based on visual selection).

You'd have to still learn Vim.

Personally, I played https://vim-adventures.com/ to get a basic grip on Vim, later I kept a cheat sheet handy, and yet later I just looked up commands and features as necessary.

I recommend disabling the arrow keys in your vim config and to just use it.

Re: Kakoune Code Editor

#174

Post by r-zip »

mikojan wrote: post #48
skavi wrote: post #12

Check out helix [0] for a kakoune inspired editor with some nice modern features included by default. [0]: https://helix-editor.com/

Have been using this instead of vim for a month now. It's incredible. No messing with plugins and archaic config files. All works out of the box, including LSP integration. Highly customizable still. Extremely fast, too. I love "space-k" (Show docs for item under cursor). The one thing I'm still struggling with is the kakoune-like movements. Maybe I'm doing something wrong, but they do feel inferior to vim's.

I agree it's nice, but Helix's default LSP for Python is unusably slow, having used pyright with Vim/Emacs/VS Code. I tried setting up the pyright language server to work with Helix, but could not get it to work. It will be much more usable once there's better documentation.

Re: Kakoune Code Editor

#175

Post by gnubison »

andrewflnr wrote: post #149
chongli wrote: post #68

Earlier quoted context omitted.

I disagree that the editing model is better than vim. It’s fancier and makes for flashier demos but I don’t think it’s better. For one thing, it places the emphasis on editing in the large . That is, its default operating mode is to leave multiple cursors all over the buffer when you’re trying to jump around your file. You have to build a habit of pressing an extra key to dismiss the multiple cursors so you don’t ina…

You can do the Vim approach just fine, and I usually do. I write prose in kak for goodness' sake, I don't usually have multiple cursors for that. The only time I accidentally get extra selections, besides old muscle memory triggering that feature in search with shift-N, is when I accidentally click in the terminal, which was going to mess me up with any editor. But occasionally it's very nice to actually have that mu…

> is when I accidentally click in the terminal, which was going to mess me up with any editor.

Well, most terminal editors don’t capture the mouse at all — this is what I personally prefer (let the terminal emulator handle it) and as a bonus it fixes this problem.

Re: Kakoune Code Editor

#176

Post by gnubison »

stjohnswarts wrote: post #55
thayne wrote: post #26

Earlier quoted context omitted.

I tried to use it enough to see if I could switch to it from (neo)vim. I liked a lot of the ideas in it, and in some ways I liked it more than vim, but it was missing some functionality that I just couldn't live without. Some things could be solved by plugins that just didn't exist yet, but others, I couldn't even see a way a plugin could be implemented. In particular, there isn't any way to get a diff mode comparabl…

I don't understand the new line thing at the end. I haven't used a utility or app in -decades- that cared about whether you have a blank final line.

Have you used cat recently? [Edit: scrolled down, looks like several other people already beat me to it. Whoops.]
Post reply on HN