Live data from Hacker News

Why Kakoune – The quest for a better code editor

kakoune.org

231–240 of 329 posts

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

#231
post #10

This looks awesome (although I think the name could use a little work). It also brings up a question I have for HN: Every few years, I make an attempt to learn to use one of the classic editors like vim or emacs, and inevitably give up after the enormous productivity drop I suffer when writing code. I just can't seem to pick up the muscle memory required to become fast with these tools, and the overwhelming array of…

> (although I think the name could use a little work)

In Japanese (書こうね), it translates roughly to "Let's write, mmkay?"

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

#232

Earlier quoted context omitted.

Sure, but the biggest problem with modern IDE's is the fact that they are terrible at editing text. IDE's and text editors overlap in their uses, but they are not the same. Sometimes you really do just have a text editing task, and none of the IDE functionality will help with it. Also, the ways in which IDE's are extensible is lacking compared to something like Emacs. Yes, they come with a bunch of built-in useful st…

Yes, they come with a bunch of built-in useful stuff, but sometimes you want to add a keybinding to do some editing task you do a lot in a particular project or company, even if it's not useful in a more general-purpose setting. Don't know what IDE you used but Netbeans is very customisable and extensible. I think this is true for IntelliJ and eclipse as well and it would surprise me if it wasn't for Visual Studio. (…

I think I probably didn't explain my meaning well. For Netbeans, Intellij, Eclipse, VS, etc. you tend to have to create a new project to write a plugin.

In Emacs, adding a simple extension is simply a matter of adding a function to your .emacs file. So adding useful functionality is very low friction, low enough that you can afford to do it when it wouldn't be worth the effort in an IDE.

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

#233

Earlier quoted context omitted.

> Here is where I'll argue that the main advantage of the big IDEs are that they have focused on UX for years. You say that, but somehow I still find the UX of every IDE I've tried to be lacking. I much prefer the UX of Emacs.

You spent (likely) years learning Emacs. How much time did you spend learning each of those IDEs you've tried? You have to realize that psychologically: you like things you're familiar with, and dislike things you're unfamiliar with. That's how top-40 radio works. That's why everybody bitches over every new software update, even when the new version is provably better. So of course you like the thing you spent years…

I've spent years in Eclipse as well (and still use it every day at work for Java stuff), and I appreciate a lot of the functionality it offers, but I definitely find the UX lacking. It's klunky. Yes, it's maybe more discoverable (although, at least in the case of Ecipse, that's debatable) and some of the keybindings are probably more familiar to most people, but I find that even though Emacs has a bit of a learning curve, once you've gotten past that, the experience of actually using it is very fluid and productive.

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

#235

Neat. One question: How can I script it? What is the scripting language for customizing the editor? I couldn’t find information on this in the documentation.

This thread explains that you script it using shell commands: https://news.ycombinator.com/item?id=13166635

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

#236
post #40

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.

To be fair, vim is somewhere around a 4th class citizen on Windows. It works, but it ain't pretty. Plus, with the unix subsystem (minus bugs) you can still run this in Windows. That still amazes me.

What exactly isn't pretty about vim (specifically gVim) on Windows?

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

#237
post #155

Earlier quoted context omitted.

If you just replace 'd' with 'y', though, the example is a good one: hitting period would just yank the same thing again. Edit: the yank example is actually way better, because you don't find out that you did something wrong until you go off and paste it somewhere else.

If you aren't sure where you'll end up with, do, in this case mmffffy`m Why would this be better? Because it works in macros too. In vim, you can record it as you go. In vi(nvi), I write it somewhere in the file, basically after I did it once, I would do Ommffffy`m^[0"wDdd and use @W later. You can of course use vim's visual mode, but in this simple case, there's not much difference.

nvi is not Vi; it's a fork of Elvis: another Vi clone, like Vim.

Vim is older than Elvis, by years.

The FOSS BSD derivatives never got the actual Vi editor of Bill Joy ancestry.

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

#238
post #144

> Kakoune’s grammar is object followed by verb This is so important. It's the reason I've stuck by Quicksilver all these years, and avoided Spotlight and whatever Google's search bar thingy is called. I've never been interested in vi because the effort to reward ratio doesn't seem favourable, but I think I'll give Kakoune a try.

Quicksilver, still? Why not move on to Alfred?

I'm not the person who mentioned QS but I'm still using it too. For me it's mostly inertia: Alfred can probably do everything I use QS for, but QS still works just fine, so why bother? When something breaks the 10% or so of QS's capabilities that I actually use beyond fixing, then I'll switch.

("Probably": last I tried using Alfred a few years ago, I think there was something I relied on QS to do that Alfred couldn't. I can't remember what it was, maybe Alfred does it now - but again, why bother? QS still does everything I want it to do.)

Also QS's interface looks cooler than Alfred's to me. Aesthetics matter.

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

#239
post #209

Earlier quoted context omitted.

because you can just write a mapping or function that does that.

How can it be helpful in the real world? If I want some repetitive behaviour (create new class, generate code) I'll use the IDE behaviour customised to my needs and in the most exotic cases I will add a generating template. But I can't ever imagine myself deleting the selection up to the fourth f from the current cursor position. For me this is not a feature, it's a huge bug because you can delete massive amount of t…

If it goes wrong, just hit u to undo.

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

#240
post #10

This looks awesome (although I think the name could use a little work). It also brings up a question I have for HN: Every few years, I make an attempt to learn to use one of the classic editors like vim or emacs, and inevitably give up after the enormous productivity drop I suffer when writing code. I just can't seem to pick up the muscle memory required to become fast with these tools, and the overwhelming array of…

> (although I think the name could use a little work) In Japanese (書こうね), it translates roughly to "Let's write, mmkay?"

Surely this isn't a coincidence?!
Post reply on HN