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

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

#51

Post by nerdponx » Tue, Dec 13, 2016, 2:52 PM UTC

masukomi wrote: post #24

greenspot wrote: post #18

If you are wondering why Kakoune and not Vim, the OP claims... (you find following passages later in his post and they don't reflect my opinion) > A design goal of Kakoune is to beat vim at its own game, while providing a cleaner editing model. > Kakoune manages to beat Vim at the keystroke count game in most cases, using much more idiomatic commands. > Kakoune provides an efficient code editing environment, both ver…

The last one is compelling, but the new "editing language" and paradigm that's been put together is _really_ compelling. Being able to see what a "sentence" is going to do as you're typing it is a huge improvement on vim. I _love_ vim, but executing complex commands is like shouting into a dark tunnel and hoping the person on the other end understands what you were trying to say.

You know there's a setting to display the current command in the status line right?

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

#52

Post by notheguyouthink » Tue, Dec 13, 2016, 2:53 PM UTC

reitanqild wrote: post #46

A better vim sounds great. That said I suspect most people would be better off learning a good IDE properly, including but not limited to: * effective navigation and selection using modifier keys and search * built in refactoring * project wide as well as single file search/replace, -and this includes regex search AND replace. This should be quite doable in less than a week compared to a few months to get equally eff…

> That said I suspect most people would be better off learning a good IDE properly, including but not limited to:

To be clear, do you think a "good IDE" is inherently better than Vim/Kako for most people?

Personally i don't see a difference in a GUI based editor and a text based editor. In fact, i quite prefer text based, because it forces an editor to treat the keyboard as a first class citizen - GUI IDEs can get lazy and revert to mouse whenever they please.

I can see the argument that Vim might not be inherently as good as a "good" GUI editor, but i don't think that is a negative towards the potential of text based editors. It just means that we need new editors to focus on the UX, imo.

With that said, i'll be quite glad that we're moving towards standardizing (of sorts) a code editor protocol so that new editors don't suffer from lack of tooling. It will be great to see a single set of tooling (formatting, linting, imports, syntax checking, etc) plug into any new editor that might pop up.

Switching editors has enough friction, tooling shouldn't be one.

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

#53

Post by soggypopsicle » Tue, Dec 13, 2016, 2:53 PM UTC

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.

Being console based is a feature for many people who spend their time in a terminal. Especially in conjunction with screen / tmux.

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

#54

Post by nerdponx » Tue, Dec 13, 2016, 2:55 PM UTC

athenot wrote: post #37

kilian wrote: post #17

Earlier quoted context omitted.

Worth noting is "kak" is one of the (many) words in Dutch for "poo". I dabble in vim and it's my editor for when I quickly want to change stuff whilst in a terminal, but not enough to be "proficient" in it. As others have noted, I feel there could be a massive gain in editing if I were to get more acquainted with the many vi commands, but the initial productivity penalty has stopped me more than once from making it m…

Hopefully this is a temporary name. Investing in branding upfront can be a waste of time but if it picks up, it might be worth a more thoughtout and friendly name.

Could be `kk`

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

#55

Post by reitanqild » Tue, Dec 13, 2016, 2:56 PM UTC

kqr wrote: post #49

reitanqild wrote: post #46

A better vim sounds great. That said I suspect most people would be better off learning a good IDE properly, including but not limited to: * effective navigation and selection using modifier keys and search * built in refactoring * project wide as well as single file search/replace, -and this includes regex search AND replace. This should be quite doable in less than a week compared to a few months to get equally eff…

But if you are like me and work in many different languages, you'll have to spend 10 weeks to learn 10 different IDEs, rather than 8 months to learn one Vim.

The ones I have used (IntelliJ, Netbeans and eclipse) were quite effortless to jump between.

I doubt Visual Studio will be much harder.

Jetbrains covers Ruby, Python, JS, C and more and it would surprise me bigtime if those language specific versions aren't quite similar to the plain Java version as well.

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

#56

Post by grive » Tue, Dec 13, 2016, 2:56 PM UTC

SeanDav wrote: 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.

It is a sensible decision, as it will focus doing things right on that particular paradigm: UNIX.

For example, this means that plugins trying to extend grammar analysis, will primarily try to rely on their already existing parsers and tools via the command line. This means a streamlined process to create plugins / extensions to the editor, and the function of the editor is well defined.

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

#57

Post by notheguyouthink » Tue, Dec 13, 2016, 2:56 PM UTC

SeanDav wrote: 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.

It blows my mind that people want Unix tools in a non-unix environment.

With that said, Windows is working on that embedded native linux thing, so i imagine it will work there.

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

#58

Post by kaoD » Tue, Dec 13, 2016, 2:58 PM UTC

nerdponx wrote: post #51

masukomi wrote: post #24

Earlier quoted context omitted.

The last one is compelling, but the new "editing language" and paradigm that's been put together is _really_ compelling. Being able to see what a "sentence" is going to do as you're typing it is a huge improvement on vim. I _love_ vim, but executing complex commands is like shouting into a dark tunnel and hoping the person on the other end understands what you were trying to say.

You know there's a setting to display the current command in the status line right?

Unless I misunderstood that won't show the result of the command.

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

#59

Post by proaralyst » Tue, Dec 13, 2016, 2:58 PM UTC

nerdponx wrote: post #51

masukomi wrote: post #24

Earlier quoted context omitted.

The last one is compelling, but the new "editing language" and paradigm that's been put together is _really_ compelling. Being able to see what a "sentence" is going to do as you're typing it is a huge improvement on vim. I _love_ vim, but executing complex commands is like shouting into a dark tunnel and hoping the person on the other end understands what you were trying to say.

You know there's a setting to display the current command in the status line right?

There's a difference in knowing what you've typed and what that means. Displaying the current chord protects against typos and losing track, but doesn't help you understand what your command is doing.

I'm not convinced I'll switch to Kakoune (as I've got a lot of momentum in Vim, not just with the editing language) but the automatic display of the _semantics_ of your current chord is an interesting idea.

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

#60

Post by hans » Tue, Dec 13, 2016, 2:59 PM UTC

Pontificating but for ide + editor replacement: someday we'll see ai/ml features that aide in opening files and keeping the right blobs of code nearby, maybe pre fetch good goog links that can drop down on a whim panel.

Even some kind of auto model visualizer that helps every so often like a replacement for the ignoble package mmanager side panel view.

We're still so stuck on text editing.