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

141–150 of 176 posts

Re: Kakoune Code Editor

#141

Post by anthk »

cduret wrote: post #101
mushufasa wrote: post #2

Does anyone use this daily? this gets posted a few times a year to HN but tbh it looks like someone just re-invented vi. Which seems kindof like creating a new religion. It can be done, but even the best televangelist isn't going to hold a candle to the spread of the catholic church.

I use it daily for many years, being a user of vim for 20 years or so. I could not come back to vim now, I find the kakoune way more efficient. I find two annoying things : - U need to make a lot of tuning to make it usable because there is now tab management, no clipboard, etc.. - U need always the last version of C++ compiler to make it compile. This is annoying on professional VMs that are way behind the current v…

>This is annoying on professional VMs that are way behind the current version of gcc.

Get binary PKGSRC packages from Joyent and set PATH accordinly.

https://pkgsrc.joyent.com/install-on-linux/

It's for RHEL and clones but it should work on any parallel distro or more recent.

Re: Kakoune Code Editor

#142

Post by lijogdfljk »

archseer wrote: post #122
Comevius wrote: post #107

There is also Helix, inspired by both Vim and Kakoune, with built-in LSP support. I'm having a great time with it. https://github.com/helix-editor/helix

Hey thanks! That's good to hear :)

Assuming you're related to Helix, how does it relate to Kakoune on the selection-first approach? That's one of my favorite features of Kakoune, curious how Helix handles that if inspired by Kakoune?

Re: Kakoune Code Editor

#143

Post by lijogdfljk »

mushufasa wrote: post #2

Does anyone use this daily? this gets posted a few times a year to HN but tbh it looks like someone just re-invented vi. Which seems kindof like creating a new religion. It can be done, but even the best televangelist isn't going to hold a candle to the spread of the catholic church.

I used Vim for ~7 years, fully switched over to Kakoune a few years ago. My primary reasons are:

1. always selection-first focused

2. multi-cursor support combined with #1 is really intuitive

That's about it really. I have it set up primarily with User Modes, to avoid modifier keys as i don't like reaching for modifiers, and i'm pretty happy.

Re: Kakoune Code Editor

#144

Post by apocolyps6 »

jzm2k wrote: post #135
usrbinbash wrote: post #130

Earlier quoted context omitted.

I used editors with multiline editing capabilities in the past. There are only 2 usecases where it was of any value to me: If I have to write multiple lines in a similar fashion, or if I have to edit the same thing in a similar fashion in several places at once. Both can be done much easier by using a regular expression.

I disagree. In the past I've used regex to do that and now that I have access to a multicursor, I won't be going back. I think with regex you don't get the same kind of visual feedback that you get from a multicursor which is why I (and many other Kakoune users as well) like it so much. If you're happier with regex and feel like you don't need multicursor, that's great.

In case it helps anyone, doing regex-based search/edit in vim was annoying until I found this plugin. https://github.com/haya14busa/incsearch.vim

Re: Kakoune Code Editor

#145

Post by reegnz »

FreeFull wrote: post #132
reegnz wrote: post #85

Earlier quoted context omitted.

> * Selecting first and then specifying an action works way better than the other way around, as it is done in the Vim family. There is visual mode in vim too you know. That's for doing exactly what you describe. I use that when I'm unsure about the movement I need for an action.

Visual mode only allows for a single selection, though

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 don't grok vi [1] which is fine, not everyone has time and passion for that. But please don't think for a moment that vim is inferior just because it doesn't blindly copy other editors features.

[0] https://engagor.github.io/blog/2018/02/21/why-vim-doesnt-nee... [1] https://stackoverflow.com/a/1220118

Re: Kakoune Code Editor

#146

Post by stonewareslord »

reegnz wrote: post #85
DJHenk wrote: post #77

Earlier quoted context omitted.

I am using it daily, as my sole editor, for a little more than a year now. Before that I used Neovim. Most important reasons for the switch are: * Leaves window management to the window manager, so it works much better with a tiling wm. I wish all applications did this. * Selecting first and then specifying an action works way better than the other way around, as it is done in the Vim family. Edit: regarding the comm…

> * Selecting first and then specifying an action works way better than the other way around, as it is done in the Vim family. There is visual mode in vim too you know. That's for doing exactly what you describe. I use that when I'm unsure about the movement I need for an action.

That's exactly what I used to say before I tried kak. I had been using vim for about 6 years and thought it sounded like vim with multi select and wasn't impressed.

The reality is, you change the way you think about editing. It took about a week away from vim but eventually I could see the selections in realtime. Not as a gimmick like with multicursor vim, but as the basis of everything. I have been using it exclusively for 2 years and haven't looked back once. Single-cursor editing is about the same speed, but selection oriented editing blows vim out of the water with anything with 2 or more edits.

It's like if a notepad user said "what's the point of vim? I can just use a mouse and arrow keys??" Vim changes the way you see things - you see a space separated word so you use W or a line with whitespace at the beginning so you use I. It's hard to explain other than you change your understanding of editing.

Edit: that gimmick comment might annoy some people. I used to use it and love it. But the reality is, it was just an add-on to an already-grest editor. After my plugin phase of vim, I realised it didn't really add much at all. So 'gimmick' is probably too harsh

Re: Kakoune Code Editor

#147

Post by thayne »

shric wrote: post #106
stjohnswarts wrote: post #55

Earlier quoted context omitted.

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.

There's a few reasons I can think of (some superficial, some significant): - Github and git will highlight a missing newline in a diff by default. - POSIX defines a line as having a newline at the end, so if you don't have a terminating new line you may have one fewer lines than you think you have [1] - If you ever want to append to a text file/source file programmatically with something like echo "something at the e…

> vim, iirc, defaults to automatically adding a newline to any file without you explicitly asking for it, unless you do set noeol and set binary or, in versions newer than 7.4, set nofixendofline

which, IMO, is the right way to do it. In kakoune however, it isn't just the default, there is no way to turn it off.

Re: Kakoune Code Editor

#148

Post by revscat »

reegnz wrote: post #145
FreeFull wrote: post #132

Earlier quoted context omitted.

Visual mode only allows for a single selection, though

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…

> vim doesn't need the fancy features of other editors (except for maybe LSP and tree-sitter for a more IDE-like experience).

Both of which neovim has.

Agree with your premise, though: (n)vim does not need multi-cursor selection, for the reasons have given.

Re: Kakoune Code Editor

#149

Post by andrewflnr »

chongli wrote: post #68
grayrest wrote: post #20

Earlier quoted context omitted.

I've gone for several week long stretches of using it but never fully converted. What winds up happening is that I get to a point in a project where I really need to focus on the code and not the editor, switch back to vim, and don't get around to switching back for another few months. The editing model is better than Vim's and if I didn't have 20 years of vim muscle memory I probably would have switched over by now.

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 multiple selection feature. For instance, suppose you have a search and replace that you only want to do on certain instances of your search, in a context dependent way. You could just use n and . repeatedly. However, I find it nicer to examine each selection, drop the inappropriate ones individually, recheck my work, then do all the edits at once. This also eliminates (granted, by defining it away) the problem of changing your mind halfway through the search process about what change you want to make. When you change your mind, your cursor is either still live in all the places, or you're done, in which case at least there's only one thing to search for again, not the half that were changed and the half you hadn't reached yet.

Re: Kakoune Code Editor

#150

Post by sidkshatriya »

hyperupcall wrote: post #113
sidkshatriya wrote: post #39

Earlier quoted context omitted.

Shelling out was a turnoff for me also initially but I've learn to embrace it. Kakoune tries not to re-invent the wheel. If sh/sed/awk/perl/other unix tools do the job well, might as well use them. That is the philosophy I think. I like the fact that using Kakoune has improved my shell script skills like crazy. (Posix) shell scripting is just everywhere and is an important skill to have. Kakoune uses shell integratio…

Sure POSIX shell scripting is a good skill to have, but I would hardly consider it good for a text editor to have that skillset be commonplace within their configuration language. Shelling out incurs a non-zero execution cost. For example with Bash, it is significantly slower execing out when using a builtin or parameter expansion will work just fine, especially with these types of quick text manipulation operations.…

> This doesn't just leave a bad taste in my mouth - it is also a giant waste of resources and causes initialization to be substantially slower compared to the alternative

I agree that shelling out on a whim that Kakoune does is a tremendous waste of CPU cycles as the OS needs to construct and tear down a whole process just to do something trivial. Having said that, in day to day usage, kakoune feels quite responsive. It's also easy to hack up plugins really quickly.

Shelling out is a crude way of getting some parallelism also. You might be surprised that constructing a new thread vs constructing a new process in Linux is not that much different resource/latency wise. Since bash/dash code is probably cached in the system memory somewhere already and libc etc are again dynamically shared, it may not be as bad to construct a whole new process. TL;DR it's bad but maybe not as bad as one thinks. It's definitely avoidable and I would not design it this way myself. I remember having to shell out once because kakscript does not know how to increment 1 to a variable and I needed dash to do that! That was one expensive +1 calculation! and I can almost imagine my CPU heating up!

Post reply on HN