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

301–310 of 329 posts

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

#301

Post by flukus »

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? Would you use a different key for the motion and the text object?

I think you've hit the nail on the head here. c3w in vim is 3Wc in kakoune, 3wc will change the third word, straight off the bat there's a lot more shift key hitting. The most annoying thing though is getting the motion wrong, if 3W turns out to not be the motion I want, hitting escape does not return the cursor to where it was before the motion.

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

#302

Post by flukus »

WhatIsDukkha wrote: post #201
brennen wrote: post #183

Earlier quoted context omitted.

Unfortunately, this is superficially true but not in practice all that helpful for a lot of us. Most vim-style input modes or plugins for other editors are woefully lacking, and even very good ones (evil mode) seem to differ enough to be uncomfortable for a subset of long-term vim users. Like: I've used Emacs extensively in the past, and certainly _could_ switch to evil if need be, but a few days of recent effort sho…

I've been using vim for decades and use evil/emacs now. It's simply not true that the vim modes outside of vim are critically lacking. In fact almost all of them support text objects and the other key parts of the vim editing experience that we are talking about here and they do it well. Some things like macros or perfect register support are not there (evil is pretty great though) but they generally have useful anal…

It's still true, most won't even allow you to remap keys or work with the system clipboard like you can in vim. Nevermind things like proper scripting and window support.

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

#303

Post by DennisP »

tigershark wrote: post #292
DennisP wrote: post #265

Earlier quoted context omitted.

Sure, I thought of that. Then instead of a variable named "salary" you've obfuscated your code by calling it a[4]. Ah, but you can just name your indexes, so it's a[salary]. But now you've got ten lines of code naming each of the index values, and a vim macro makes it faster to write again. In any case, macros are just one of the features that make vim productive. I find that I do a lot more small refactors when I'm…

Or as I suggested earlier you just use objects instead of random variables. employee = new Employee(); And you have all the fields reinitialized to the correct default value (that can be different from zero) and much better naming because now you can tell the difference between employee.Username and user.Username

Sure, and I do that when I can (e.g. not when I'm writing SQL), but the point of my quick examples isn't to show off my software engineering, but to illustrate what vim can do in the simplest way I can think of.

I guess I'm failing to make the point, so I'll just refer to the articles that got me to try it in the first place.

http://www.viemu.com/a-why-vi-vim.html

http://www.moolenaar.net/habits.html

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

#304

Post by wangchow »

rimantas wrote: post #250
wangchow wrote: post #245

Earlier quoted context omitted.

In this age we need to think about things like voice control and 3D manipulation of data-structures and a dynamic view of the code. We can truthfully keep designing 2D editors (and we will always most likely use them to some extent) but I believe it is more important to consider different UI paradigms altogether. For instance, what about editing a living code environment? Game development is very immersive: you can m…

> We have all the technology. > It's time to get to the next level. Just because you can does not mean you should. Dictating code may be useful is you cannot use your hands, but that's about it. In all other cases there is no benefits of doing that.

Well consider if you use both dictation and typing simultaneously. Vi and kakoune are ergonomic because it requires minimum changes to hand positions. But if you added voice dictation like "toggle tab 2" or "toggle terminal" or "go next brace" etc, all while STILL typing my guess is efficiency would go up physical fatigue would go down.

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

#305

Post by notheguyouthink »

favadi wrote: post #280
notheguyouthink wrote: post #86

Earlier quoted context omitted.

I know you're seeing a ton of "yes it's worth it" posts, but i just wanted to add a slightly different perspective. Yes, it's worth it even when you aren't an expert at Vim. I am constantly learning new Vim commands[1], and i feel i only know a tiny fraction of the vim editing language. Yet, i still love vim, and use it constantly, for everything. The approach i take, as to make it enjoyable and not a job, is: "is wh…

Should be using ace-jump instead of counting the lines.

Not familiar with ace-jump, but i don't count lines. I use relative line numbers, and just hit the number i want to go down to. Ie, it will say 15 below me, so i hit `15j` if i want to go there.

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

#306

Post by 746F7475 »

tigershark wrote: post #207
jxy wrote: post #155

Earlier quoted context omitted.

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.

Seriously? What is the advantage of using your cognitive capabilities to write Ommffffy`m^[0"wDdd rather than use a sensible IDE with common refactoring capabilities that are also context aware and integrated with the language you are using?

Have you seriously never ran into a situation where your IDE does almost what you want, but you still have to do some bit of it manually just because IDE can't handle this specific thing or format or whatever? If so you are either spending way more time thinking about your architecture and code before writing anything than most people or your IDE is fucking amazing.

While remembering long button combinations seems hard and tedious and "strain on cognitive capabilites" they really are just chained commands. In the idea world you don't think: "now I just have to hit v4w"+y to copy these things to clip board", but instead: "I'll copy next four words into clip board" and then just execute the commands. Same goes to longer commands, instead of hunting down some hidden feature in your IDE, you can just bang out chain of commands you wish to execute.

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

#307

Post by yekim »

ncd wrote: 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…

No, it's not worth it. Modern IDEs make so many things easier than vi / vim / emacs ever did.

vi / vim / emacs can be useful in certain situations (Unix / Cygwin command lines, low level embedded systems that don't have a desktop, etc), but for most code, the modern IDE GUIs blow them away. Code navigation / inspection / contextual browsing is much, much better, easier, and far more productive using Eclipse, CLion, Visual Studio, etc.

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

#308

Post by cwp »

lilyball wrote: post #204
cwp wrote: 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 tried Alfred when it came out. Then, it didn't support that object, verb grammar that Quicksilver did. Does it do that now?

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

#309

Post by nameless912 »

MetaCosm wrote: post #236
falcolas wrote: post #43

Earlier quoted context omitted.

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?

The default fonts, the menus, the menu icons, the font rendering, the inability to use many plugins....

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

#310

Post by jerkstate »

I tried this editor out and the most maddening thing was figuring out how to reduce multiple cursors back down to one. I finally figured out - by accident - that pressing the space bar reduces your number of cursors down to one. The documentation needs to make this basic, necessary key-command a lot more obvious.
Post reply on HN