I was pleasantly surprised at how good it is. Definitely keeping an eye on it.
Why Kakoune – The quest for a better code editor
171–180 of 329 posts
Re: Why Kakoune – The quest for a better code editor
#172Earlier quoted context omitted.
To be clear, do you think a "good IDE" is inherently better than Vim/Kako for most people? Right now, for most people: very much yes. 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. Fair point. However: Betwe…
> Here is where I'll argue that the main advantage of the big IDEs are that they have focused on UX for years. You say that, but somehow I still find the UX of every IDE I've tried to be lacking. I much prefer the UX of Emacs.
You spent (likely) years learning Emacs. How much time did you spend learning each of those IDEs you've tried?
You have to realize that psychologically: you like things you're familiar with, and dislike things you're unfamiliar with. That's how top-40 radio works. That's why everybody bitches over every new software update, even when the new version is provably better.
So of course you like the thing you spent years with over the thing you tried to learn for a week and a half then gave up on because Emacs is better. That has nothing to do with UX.
Re: Why Kakoune – The quest for a better code editor
#173Earlier 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.
Why not just "ki"?
Re: Why Kakoune – The quest for a better code editor
#174The 'd2tf' example is just wrong... after realizing I didn't hit the right 'f' I would just press '.' (not 'ud2tf')... I think I will stay with vim for now, also the discoverability could be better... Btw. mixing vim with tmux also solves the 'command line next to editor' problem.
Re: Why Kakoune – The quest for a better code editor
#175A few things I like: * No NodeJS/NPM * No Electron * No multi-threading
No multi threading is a plus?
From Design notes:
> "No threading: multithreading is a hard problem, and is not well suited to a text editor:
Either we want a direct result, and we need to be synchronous with the user, so getting a 4x speed up is meaningless, we need to have an algorithm which appears instantaneous the user.
Or we want an asynchronous result, and then the processing is best left to a helper command which can be reused with other Unix tools."
I agree with them. Multithreading today in all situations is like Fuzzy logic of yesteryears. It is suppose to make everything better.
Re: Why Kakoune – The quest for a better code editor
#176This 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…
No, in my opinion. The problem is the people who reply will be the people for whom vim and Emacs "clicked". I'm like you, and when I looked at my vim using friends, they really aren't any more efficient. Also, while your editor will "work forever", expect interesting plugins (like C++ integration via clang) to be less stable than say atom or visual studio, and to have to nice plugins every few years. Also, they don't…
Emacs user here. No it didn't just "click" with me. I was learning Lisp and learning Emacs became a necessity. I don't think it was easy for anyone to learn Emacs or Vim. It takes a lot effort to learn these tools. In my case, it took about 2 months before I felt like I was efficient with the text editing, and I still learn new things today.
If it matters, I don't think many people can program any faster than I can in Emacs, especially against macros, interesting plugins, functions, and snippets.
There is a trope about how a new Emacs user will be faster than most Vim users, but watching an expert Vim user work blows the best Emacs / IDE user out of the water.
Re: Why Kakoune – The quest for a better code editor
#177Earlier quoted context omitted.
To be clear, do you think a "good IDE" is inherently better than Vim/Kako for most people? Right now, for most people: very much yes. 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. Fair point. However: Betwe…
> Here is where I'll argue that the main advantage of the big IDEs are that they have focused on UX for years. Yea, i definitely agree there. It's also that GUI IDEs tend to cater towards.. well, a different crowd. What that means in real world terms in often a product with rough edges, confusing patterns, and a horribly steep learning curve. I enjoy seeing products and languages (programming) focus on learning as co…
Meanwhile, Git has taken over all source control for development despite being possibly one of the worst applications ever created. (Hell, even Lotus Notes tried to be usable-- it failed, but it tried.)
It's a lost cause in this industry.
Re: Why Kakoune – The quest for a better code editor
#178I don't want to belittle anyone's work or inventions, but I think modal editors are old and outdated. They've had their time in my mind. Bret Victor gave a great talk about programming and tools: https://vimeo.com/36579366 His talks always blow me away.
On the contrary, my reaction to reading OP was, "wow, somebody brought Bret Victor's ideas to modal editors!" The goal of switching verb and object is precisely to stop drawing dead fish (http://worrydream.com/#!/StopDrawingDeadFish)
Re: Why Kakoune – The quest for a better code editor
#179One 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…
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, I may use some shell commands to refactor bunch of js/html/css/java/sql code with single or few find and perl -pie commands, all at once. When I need to do an another refactoring, I can pickup previous refactoring command from shell history or I even can put command into script, so I will have my own refactoring tool. Regular expressions are fragile when used with code, but I can undo changes with git and repeat. They are saving lot of typing, so I prefer to spend few minutes in console than a hour in IDE. Vim has lot of commands built-in, so it's even easier to do a refactoring in Vim, but IDE's built-in refactoring is still better, when available.
Re: Why Kakoune – The quest for a better code editor
#180Earlier quoted context omitted.
Oh that makes a lot of sense, that's probably the origin of the name. The project is quite a bit older than that though (>4 years).
It's a new caledonian word, see https://github.com/mawww/kakoune/blob/master/doc/manpages/fa...
Thanks for digging into the docs and finding the actual meaning. I didn't see anything in the readme.md :)