Live data from Hacker News

Why Kakoune – The quest for a better code editor

kakoune.org

91–100 of 329 posts

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

#91
post #83

Earlier quoted context omitted.

For example the fact that the terminal does not make any difference between and . Or and .

How is that destructive? Visual editors assign various non-editing tasks to command sequences as well. Pycharm moves the cursor around parenthesis with C-m for example, Cmd-M minimizes windows, and Cmd-I does formatting.

I don't understand what you mean. It's destructive in the sense that the raw input is not even being passed to the application in the terminal.

No applications running in the terminal will be able to tell the difference between these two different key presses.

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

#92
post #60

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.

All this exists in various IDE's for various languages (except the prefetch of 'good' google links) re keeping related code globs around. In particular Netbeans IDE supports a lot of dynamic languages. It's php, python, and javascript plugins all offer project views other than "what's on the filesystem", intellisense, code completion as you type. I suggest spending time exploring existing options if one hasn't.

RE editing text: whatever code object model one can imagine, it generally always serializes to text. I for one don't see the benefit of editing an abstract model in place of text. An example I liked was Fortress [1]. Fortress was a language that attempted to let users write code in mathematical notation using a special latex editor (iirc). It was found to be not a huge win, and they reverted to 'normal' syntax. This was one of Guy Steeles projects at sun.

So having said that, there are languages where editing the model is editing text: Lisp and Scheme.

[1] https://en.wikipedia.org/wiki/Fortress_(programming_language...

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

#93
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 also tried a few times, always failing (apart from basic survival, i.e. :qa! to quit ASAP...); I finally learnt vim when I was forced to at my previous workplace, because our main work environment was on remote servers with crappy connection.

I always said that love for vim is an example of Stockholm Syndrome; and now I'm using it daily as my main editor of choice. The killer feature for me is :cex system('foobar | grep something | ...') | copen. Other than that, various plugins, especially for Go (vim/emacs/acme(?) have the most mature plugin ecosystem for Go) and CtrlP. My current opinion is that vim is in some ways super cringeworthy, but in other ways lightyears ahead of competition. And as to the Stockholm Syndrome... I'm kinda on the fence now. But then... isn't it actually what the Syndrome is all about?...

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

#94
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…

If you want to board a train, you don't try to jump in through an open window while it's moving at full speed. Emacs and vim are very fast trains with very slow acceleration. You're going to spend days, possibly weeks, struggling to do things that were trivial in your old editor as you get up to speed.

If you can't afford that during your productive coding hours, you'll need to set aside dedicated time to be productive at learning - time when practicing vim or Emacs is the only goal. Run through vimtutor or the Emacs tutorial (Ctrl-h t) to learn the basics, then run through it again. Repeat until you can do the tasks without reading the parts explaining the commands.

Grab a random long file of code, make a copy, open the copy in your editor. Practice navigating - pick a character on the screen, work out a fast way to get there without touching the keyboard, then execute it. Practice selecting words, bracket/quote-delimited chunks, lines, functions. Practice making small but precise edits. Get used to the different paradigm of cut/copy/paste that both use, including registers (vim) or the kill ring (Emacs). Practice using searches to move around, and also search/replace.

Learn how to use the built-in help. Both Emacs and vim have amazing help systems that cover every default keybind, built-in command and user-customizable setting.

Do all of the above without any customizations or plugins. After you've mastered the basics, you can start customizing, but try to only do it to fix pain you've already experienced rather than add things you might need some day.

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

#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'm just typing it into one file, making a few decisions about whether to put all of the factory functions at the top and have the instances at the bottom, etc. It lets me focus on:

  -Opening files
  -Saving (:w to keep the file open, :x to save and close)
  -Basic copy/paste
  -Navigating around the file
  -Switching modes
I've spent a few nights messing around over the last week and I feel like I'm picking it up. I like not having to do much with the mouse since I have a bad habit of straining my arm/wrist by holding the mouse while I'm not using it (while reading). Keeping my hands on the keyboard feels more comfortable and ballanced.

It's too early in my usage to say whether it's worth it or not, but I feel confident that being familiar with other text-editing 'paradigms' is a good thing.

[1] http://javascript.crockford.com/tdop/tdop.html

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

#96

I liked the ideas and especially the paperclip :) I couldn't find whether it is completely written from scratch or a vim fork? If not, why is it not a vim fork?

The code statistics on github[1] show almost all C++, while vim is written in C. According to the author the project began as a reimplementation or merely a rewrite of vim then turned into a more ambitious reimagining of how to design a modal editor.

[1] https://github.com/mawww/kakoune

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

#97
post #37

Earlier quoted context omitted.

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`

And that is short for cancer in Dutch, used as a swear word.

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

#98

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.

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 much illustrates my other general strategy, which is to edit incrementally without worrying about getting each command perfect.

(Which is not to say I don't find Kakoune intriguing.)

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

#99
post #73

One functionality I find missing in all modern code editors is - repeat action. This was present and extremely useful in, now extinct, Convergent Technology OS (CTOS) resident editor. In brief, it allowed users to repeat all the actions they performed on one-line of code, on another line of code. It's amazing how productive you can be when you have that feature. This goes beyond find & replace; It also helps format c…

> It also helps format code, insert, replace multiple parts of the line, etc. all with one keystroke.

Can't you achieve all this via multiple selections (eg. ctrl+d in Sublime) and acting on them?

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

#100
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 just installed vim on the side and used it for little notes and so on. After a while I started missing the basic movement keys in my IDE, and installed an emulator. For two weeks it was utter pain and then I was back to normal productivity. Over time I gradually added little tricks and now it drives me crazy to go back.
Post reply on HN