Live data from Hacker News

Why Kakoune – The quest for a better code editor

kakoune.org

291–300 of 329 posts

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

#291
post #290

Earlier quoted context omitted.

Mutli cursor. There is plugins which try to emulate it, but it either didn't work or was lacking a lot functionnality. Other things bothered me, but the lack of good multi cursor implementation was a reason to stop using vim by itself. Just can't live without it now.

Multi-cursor seems very anti-DRY. If you have parts of code that share so much structure that multi-cursors are useful, you likely want to factor them out.

The most common use case that can't be factored out would be sql.

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

#292

Earlier quoted context omitted.

The second example that you made is perfect for my point. Why in the world I would possibly want to have 10 different variables, all of them explicitly reinitialised to zero, if I can just write "a = new int[10]" ? (And it is so compact that it doesn't even deserve the indentation to make it verbatim) And if the variables are completely independent then much, much better to use some unit of measure or different objec…

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

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

#293
post #35
post #32

Earlier quoted context omitted.

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? 'w' will move the current selection to the next word so only one word. To extend the selection you need to press 'W' so "wWWWd" will delete four words. For most motions (if not all), the uppercase variant will extend the current selection. This also makes searching slightly different: / search forwards ? extend se…

w irritates me, because it always traverses a bunch of miscellaneous symbols, and my brain can't parse fast enough to easily tell in advance how many times I'll have to press w in order to get where I want. Extremely minor, but extremely niggly annoyance. I've found myself using https://github.com/justinmk/vim-sneak more and more often.

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

#294

Earlier quoted context omitted.

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…

QS was seriously broken for a long time. I understand someone else finally picked it up and started fixing the bugs, but I don't know why anyone actually kept with QS during the long broken period.

Even back when QS was under active development by the original author, it was still pretty buggy. I actually had a separate keyboard shortcuts app running in the background with a single shortcut which would relaunch QS for those times when QS decided to crash.

I am curious what you relied on QS for that Alfred can't do. Everything I remember doing with QS is doable with Alfred.

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

#297

I'm still waiting for someone to do a modal abstract syntax tree editor. You would only type text when naming something, the other mode would be for navigating the AST.

Sounds like a visual scripting system with low level constructs.

Visual scripting is nice in that you can have a seperate presentation layer on top of the language syntax. There's a lot of potential in improved readability that way I think. Most visual scripting depends on mouse actions, which is kind of slow and I suspect a big reason why programmers dislike it so much.

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

#299
post #35

Earlier quoted context omitted.

>How would that work if the motion comes first? Would I go "wwwwd"? Would that delete one word, or four? 'w' will move the current selection to the next word so only one word. To extend the selection you need to press 'W' so "wWWWd" will delete four words. For most motions (if not all), the uppercase variant will extend the current selection. This also makes searching slightly different: / search forwards ? extend se…

w irritates me, because it always traverses a bunch of miscellaneous symbols, and my brain can't parse fast enough to easily tell in advance how many times I'll have to press w in order to get where I want. Extremely minor, but extremely niggly annoyance. I've found myself using https://github.com/justinmk/vim-sneak more and more often.

You might also like quick-scope:

https://github.com/unblevable/quick-scope

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

#300
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.

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.

Wikipedia has Elvis predating Vim by nearly 2 years (January 1990 vs. November 1991).

While nvi isn't vi, it was intended to be "bug-for-bug compatible" with Joy's original vi. It's not quite there, but it is much closer than any of the other vi clones.

The FOSS BSD derivatives can have a vi descended from Joy's: `2bsd-vi` in FreeBSD's ports collection, `traditional-vi` in OpenBSD's ports collection, `ex` in NetBSD's pkgsrc collection. Or anyone can nab it from http://ex-vi.sf.net/ ;)

Post reply on HN