Live data from Hacker News

Why Kakoune – The quest for a better code editor

kakoune.org

181–190 of 329 posts

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

#182
post #149

One of the nice things about being an Emacs user (hang in there, I have a real point about Vim to make) is that the concepts (especially non-modal editing) and the keyboard shortcuts map well to newer IDEs. I switch between IntelliJ and Emacs all day, and all I had to do to become comfortable is choose the Emacs keyboard preset in the IntelliJ preferences. The same is true for Eclipse and Visual Studio. The Emacs par…

That's precisely what makes Kakoune interesting. There are tons of Emacs-alikes out there, environments that do what Emacs did in a more modern way. There are basically no Vim-alikes out there, things that take Vim's conceptual underpinnings and do them differently in a way that is unambiguously not Vim.

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

#183
post #149

One of the nice things about being an Emacs user (hang in there, I have a real point about Vim to make) is that the concepts (especially non-modal editing) and the keyboard shortcuts map well to newer IDEs. I switch between IntelliJ and Emacs all day, and all I had to do to become comfortable is choose the Emacs keyboard preset in the IntelliJ preferences. The same is true for Eclipse and Visual Studio. The Emacs par…

I find that nearly all editors have VIM "mode" that will allow you to just use the vim key bindings, so it's not really a problem swapping between two editors. They tend to have an emacs mode as well, in case you're interested in using your emacs keys.

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 showed me that the switching costs are higher than I'm willing to pay right now, and it's not clear I'd be any better off in the end.

Whatever the infelicities of vim's implementation (there are certainly plenty), I think there's a tendency to underestimate the expressive nuance and (for lack of better words) complex texture of the interface.

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

#184
Problem with all these hotkeys is discoverability and memory. In the end, I use just a few well known hotkeys. It's useless to define hundreds of them. I don't like modal editors especially because keys have even more functions then, which I have to remember.

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

#185
post #17
post #11

I'm sorry... but "kak"? I love/like vi[m], I love/like emacs... I ... never mind lol The new editing language does look great, and I like the idea of the piped filters... but I can't get over the name :-/

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…

Same here. «kaka» — poo/bad thing, «kakoune» — somebody who does lot of poo. :-)

However, «vi» means visual, while it is the least visual editor among popular editors, so I expect by analogy that kak will be very good editor. Keep fingers crossed. :-)

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

#187
post #145
post #76

Earlier quoted context omitted.

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

It does? I wouldn't mind finding out how Sublime, Atom and VSCode do it.

Atom has [0] which I use from time to time. I don't use the other two, but as far as I understand Sublime has support for macros built-in, and VS Code is still pretty young and will probably get something similar once its ecosystem grows.

I rarely use ad-hoc recorded macros. Like the author of Kakoune, I think multi-cursors feel much more natural.

[0] https://atom.io/packages/atom-keyboard-macros

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

#188
post #95
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'm learning Vi(m) right now because next semester our C++ course (programming 2) will be taught within a UNIX environment. I'm new to linux as well, so after recently installing Fedora, I limited myself to using Vim as a way of practicing. So far it has helped to work on a project that involves typing in source code that has already been laid out (its Douglas Crockford's essay[1] on writing a JS parser). Literally I…

You can install mc file manager (dnf install mc), and can use built-in editor mcedit for codding. ^O will switch to console (^C^O to switch back to editor), so it's easy to code and test console applications. It's a lot less powerful than vim/emacs, but it's easy to learn and use.

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

#189
Shameless plug: I have been working on my own code editor as well, I wanted something between Notepad++ and Jupyter Notebooks; I called it TeIDE: https://github.com/omtinez/teide

Fully open source, built on Polymer and currently working on a plugin/action model to enable users to execute custom commands on the underlying shell.

Accepting pull requests and all forms of feedback :-)

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

#190

Earlier quoted context omitted.

The core "IDE" features you don't normally get with an editor are things like project views, intellisense, code completion as you type, real time parsing and error highlight, code navigation. Sure you can get most all of this by wrangling plugins for vim (or which ever editor you choose) but in an IDE like eclipse, netbeans, intellij, visual studio, it's all there, ready to go. In effect, a modern IDE is "programming…

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.

(In fact I think I have seen vim modes for all of these and even embedded vim in eclipse.)

Post reply on HN