Why Kakoune – The quest for a better code editor • Hacker News Board

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

#191

Post by hobofan » Tue, Dec 13, 2016, 6:23 PM UTC

lisivka wrote: post #179

hobofan wrote: post #76

Earlier quoted context omitted.

I don't know what you are talking about. Every major editor I know has that functionality.

I'm not a huge fan of vim: I used vim a lot for a 1,5 year, then switched to IDE with refactoring (CodeGuide was one of the first IDE's with refactoring for Java). When a IDE supports refactoring, e.g. it can swap order of arguments in calls to function, it helps a lot. But when the IDE does not support refactoring of language of your choice, vim can help to do a refactoring of code manually much faster. For example,…

Reply to the wrong comment?

Regardless, I think that the missing refactoring capabilities of code editors are only a symptom of missing command line tools for refactoring. Hell, very few languages have good open source tools for linting and static analysis which is more or less a required building block for good refactoring tools.

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

#192

Post by lunchboxsushi » Tue, Dec 13, 2016, 6:24 PM UTC

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…

I've found that for Node.JS / Golang / PHP / JavaScript it has been well worth it, my workflow feels faster, I have less time spent missing clicking around even copying a line or changing text inside quotes or braces. Things like ci" or da" make life a lot easier dealing with parenthesis. The editing capabilities just feel natural I always feel like I'm programming and not just 'thinking' I believe it just comes fluently from practice and motivation for learning it. I prefer Emacs + Evil (vim modal editing) due to ELisp and I started with Emacs first never gave VIM a chance.

I also find the packages out there are pure genius such as ace-jump (originally from vim i know..)

but don't even bother for anything .NET or Java.

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

#193

Post by saosebastiao » Tue, Dec 13, 2016, 6:25 PM UTC

I love this idea, and look forward to trying it when I have a little more disposable time to learn something new. I just want to point out one thing: While it is admirable that this project sticks to just text editing, our text editors often form a part of a system. This includes IDEs, shells and interpreters, and the OS itself. One of the missing "modes" of vim is a yield-to-something-other-than-editor mode. Because we don't have this, any time I use vim or a vim compatibility layer, I end up having to remap keys from their defaults to something that I have trouble remembering and is completely different from the docs. I hate remapping keys. Give us a mode that allows us to keep the rest of our ecosystem intact.

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

#194

Post by kstenerud » Tue, Dec 13, 2016, 6:26 PM UTC

Blah blah blah another "modal editing is better" article.

And once again, I'm not impressed. You may not like GUIs, but I do. You may think that keeping your hands on the keyboard and off the mouse makes you more productive, but I don't.

We all have our preferences. Yours are not better than mine. End of story.

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

#195

Post by gdmeteor » Tue, Dec 13, 2016, 6:28 PM UTC

I've actually never heard of Kakoune. And I'm not too familiar with verb based text editors in general. I've been using Visual Studio Code recently and like it functionality wise.

http://jsdiaries.com/2016/11/27/visual-studio-code-features-...

I may move on to a verb based editor like this as my projects getting more complex and navigating through verb commands is a must. But can someone tell me what languages would benefit most from an editor like Kakoune? I'm assuming creating macros would be a big part of using it ?

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

#196

Post by zem » Tue, Dec 13, 2016, 6:34 PM UTC

kstenerud wrote: post #194

Blah blah blah another "modal editing is better" article. And once again, I'm not impressed. You may not like GUIs, but I do. You may think that keeping your hands on the keyboard and off the mouse makes you more productive, but I don't. We all have our preferences. Yours are not better than mine. End of story.

they're not mutually exclusive. vim's modal features are handy even if you use gvim - e.g. you could select a range of text with the mouse and use y to yank it because you were in editing rather than insert mode

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

#197

Post by nonsince » Tue, Dec 13, 2016, 6:37 PM UTC

This is awesome, I only wish it was a mode integrated into Emacs, like evil-mode. I can't afford to give up the debugging, completion etc. that I get as part of emacs, but I would love to use this in my day-to-day flow.

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

#198

Post by martanne » Tue, Dec 13, 2016, 6:39 PM UTC

jxy wrote: post #122

DennisP wrote: post #98

Earlier quoted context omitted.

That's why I tend to use visual mode. It sounds like Kakoune is basically visual mode by default, which is cool but not that different. This example was a bit silly: "dtf will delete to next f, if you then realize that was one f before the one you targeted, you need to undo, go back to your initial position, and try again with d2tf." There's no need to undo. Just follow up with a dot and you're done. Which pretty muc…

Which is to say that they don't understand vim, or rather, they don't even grok vi. You can't beat your enemy if you don't understand your enemy. "Go ahead and down vote more, I just wish you guys can learn more of vi, so you can truly deliver something better. So far, these surface scratching alterations only build on irritations of those vi first-timers. Good luck. "By the way, I use acme when I have graphics inter…

You can be sure that the Kakoune authors are familiar with vi(m).

Having said that, if you like both vi(m) and the structural regular expression support of sam/acme you might be interested in vis which combines the two:

https://github.com/martanne/vis

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

#199

Post by lisivka » Tue, Dec 13, 2016, 6:41 PM UTC

hobofan wrote: post #191

lisivka wrote: post #179

Earlier quoted context omitted.

I'm not a huge fan of vim: I used vim a lot for a 1,5 year, then switched to IDE with refactoring (CodeGuide was one of the first IDE's with refactoring for Java). When a IDE supports refactoring, e.g. it can swap order of arguments in calls to function, it helps a lot. But when the IDE does not support refactoring of language of your choice, vim can help to do a refactoring of code manually much faster. For example,…

Reply to the wrong comment? Regardless, I think that the missing refactoring capabilities of code editors are only a symptom of missing command line tools for refactoring. Hell, very few languages have good open source tools for linting and static analysis which is more or less a required building block for good refactoring tools.

I'm trying to argue why Vim may be better than regular editor with my own experience, which is not strongly sided.

BTW.

I also found that when I cannot use full size keyboard, e.g. phone, tablet, or netbook, vim is usable, while regular editor is hard to use because of lack of essential keys, but I rarely use phone for development.

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

#200

Post by farresito » Tue, Dec 13, 2016, 6:43 PM UTC

falcolas wrote: post #45

IshKebab wrote: post #38

Modal text editors are definitely not my thing, but anyway this looks like a huge improvement on vim. Still a shame that it is entirely console-based. It's 2016 people! We've had GUIs for literally decades.

What would a GUI bring to this that isn't possible in the console? You can use a mouse to issue commands to console programs, after all: if you want to use your mouse to scroll through or select regions of text, you can.

If I'm not mistaken, the reason vim doesn't allow a lot of key bindings (like control+shift+key, control+symbol) is because of the terminal, so in theory a GUI should allow to bind them.