Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Kakoune – The quest for a better code editor

kakoune.org

Post reply on HN
Print view View original

111–120 of 329 posts

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

#111

Post by elbows »

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…

When I started with Emacs, I customized a bunch of things to make it behave in a more familiar way. That let me learn new things in small batches without taking a huge up-front productivity hit.

Over time I've changed a lot of things to be closer to defaults. But I've also kept some of my customizations (I still use cua-mode, for example).

One downside to this approach is that you may miss out on useful parts of Emacs because your customizations cover them up or conflict with them. But on the whole it has worked very well for me.

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

#113

Post by Unbeliever69 »

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 find that having a good cheat sheet in front of me helps a lot. A good book goes a long way. I recommend Practical Vim by Drew Neil. And of course, use it when you are not programming on the clock. I find that this is the best way to develop the muscle memory.

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

#114

Post by doppioandante »

aamederen wrote: post #2

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?

It is written from scratch in a very modern C++ style, I advise every C++ programmer to look at it. Also the code is quite well organized.

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

#116

Post by Steeeve »

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…

> is it worth it?

Absolutely!

--- When I got back into emacs I dedicated two weeks to re-learn it after years of not using it.

I watched/read a couple of tutorials for setting up a python development environment - which happened to be one of my drivers since I hadn't found a decent python editor.

I read through the built in tutorial once, and referenced it a few times in the following days as I was editing. I had coding to do, but I did manage to slim down my task list to account for the potential of lost productivity.

For emacs M-x describe-mode was very helpful in getting a list of chords/hotkeys, but the ones that I really needed to develop a memory for were navigation/search/save/exit.

It probably was the full two weeks before I was comfortable. Now I get into other environments and I wonder how people deal with how slow things are or how you are supposed to remain focused when you have to use your mouse all the time.

My favorite plugin is yasnippet. Quick and easy templates for repetitive tasks with multiple stop points and dynamic content.

After that, any effort is simply in googling what you need your editor to do. If it's not built in, somebody has already wrote something for it 90% of the time.

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

#117

Post by SubiculumCode »

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…

http://vim-adventures.com/

An adventure game using vim. May help you learn.

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

#118

Post by tomku »

notheguyouthink wrote: post #86
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 know you're seeing a ton of "yes it's worth it" posts, but i just wanted to add a slightly different perspective. Yes, it's worth it even when you aren't an expert at Vim. I am constantly learning new Vim commands[1], and i feel i only know a tiny fraction of the vim editing language. Yet, i still love vim, and use it constantly, for everything. The approach i take, as to make it enjoyable and not a job, is: "is wh…

Strongly endorsing the "make the pain go away" path to learning, but I'd also like to mention a secret weapon for really nailing down the more powerful movement and editing commands in vim: macros.

Macros are immensely useful themselves and everyone should learn and use them, but they have another benefit beyond simple utility - writing good macros requires using commands that generalize rather than "eyeballing" how many times you should press a key. If you want to move to the next paragraph in a macro, you can't just mash j until you're there because every use of the macro might require moving a different number of lines. What you can do is use { and }, vim's built-in commands for moving by paragraphs that are underused because holding down j is "good enough" for interactive use. I find that after I start using a command to make better macros, it filters into my interactive use soon after.

As a bonus, using more powerful motions instead of repeating weaker motions makes your macros execute a lot faster.

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

#119

Post by throwaway991872 »

gbersac wrote: post #72
throwaway109211 wrote: post #64

Earlier quoted context omitted.

I think Vim is far easier to learn than Visual Studio. The menus are completely unintuitive, bureaucratic and painful to use. I always use cl.exe from the command line with Makefiles.

I think it is very hard to be more unintuitive than vim.

Vim is unintuitive at first, but there's excellent documentation.

With Visual Studio, the documentation is horrible, you always encounter stale links to unorganized and regularly changing microsoft.com websites.

Relatively basic things are left unexplained and documentation is outsourced to Stackoverflow:

1) How do I restore the output window I clicked it away in order to make the editor usable in the first place?

2) What the heck is a "project" and why do I need one?

3) Why do I need so many frigging clicks to get to the debugger (the debugger itself is nice though I have to admit)?

The list goes on an on. All these things are far simpler with vim and gdb: Need to debug x87 fpu registers? One simple google search and you have an instructive plaintext website that tells you everything and off you go.

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

#120

Post by _binder »

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

Reminds me of helm and ivy in emacs
Post reply on HN