Live data from Hacker News

Why Kakoune – The quest for a better code editor

kakoune.org

241–250 of 329 posts

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

#241
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.

I'm not against text underneath, just the sense logic needs to get much better with dev tools. it's like we're ignoring our own needs :] intellij + eclipse (worse), and that old model of an IDE requires too much elbow wringing and imo never sense's the right stuff to really groove with my work. there's more that could come with ai/ml for tooling, and hopefully soon.

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

#242
post #69
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…

Definitely not. I learned vim for three month. After a vimrc of close to 150 lines, I had to admit that sublime text has more functionality than vim and all of them are far more difficult and slow to use (long and hard to memorize command names). It's even worst compared with IDEA. Now I only use vim as my default editor in terminal. Just use sublime, or even better, IDEA.

I don't use either editor, but just out of curiosity, what functionality is in Sublime that Vim is missing? Multiple cursors? Certain plugins?

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

#243
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.

Yeah, God knows that I only learn tools that I can use at any time, anywhere, on any hypothetical machine. Not the machines I actually own, but ANY MACHINE EVER. This smells like confirmation bias to me.

> "Yeah, God knows that I only learn tools that I can use at any time, anywhere, on any hypothetical machine. Not the machines I actually own, but ANY MACHINE EVER."

This is a straw man argument.

I already use perfectly good multi platform editors like Sublime and Vim and I have Emacs as an option, although I have not used it much. There is a significant investment in time required to use a modal editor like Vim (and apparently Kakoune) at even close to a decent level. I simply prefer to not have to change editors every time I change platform, since an editor is a tool I use a lot and I have the option to not be restricted by platform limited editors.

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

#244
post #209

Earlier quoted context omitted.

because you can just write a mapping or function that does that.

How can it be helpful in the real world? If I want some repetitive behaviour (create new class, generate code) I'll use the IDE behaviour customised to my needs and in the most exotic cases I will add a generating template. But I can't ever imagine myself deleting the selection up to the fourth f from the current cursor position. For me this is not a feature, it's a huge bug because you can delete massive amount of t…

> If I want some repetitive behaviour (create new class, generate code) I'll use the [...] behaviour customised to my needs

AKA a function.

> code editor is to be context aware and transform your code accordingly to the language rules, not just blindingly execute a series of commands

If you "blindingly" execute a series of commands in anything, it's not going to end well. Also, vim can load commands/plugins based on filetype, or any arbitrary condition you want.

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

#245

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…

In this age we need to think about things like voice control and 3D manipulation of data-structures and a dynamic view of the code.

We can truthfully keep designing 2D editors (and we will always most likely use them to some extent) but I believe it is more important to consider different UI paradigms altogether.

For instance, what about editing a living code environment? Game development is very immersive: you can manipulate a running environment and see results immediately. How can this be extended to other development tasks like server-side development?

What if, when you select a for loop from code fragment a 3D visualization of the programs data structures at that point is shown to the user. What if you can, instead of launching a debugger, run the debugger as you're writing the code and step forward and back and see these visualizations change?

We have all the technology. It's time to get to the next level.

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

#246
post #227

Earlier quoted context omitted.

I think we need to first get over the hurdle of "code == text". I mean, the features you talk about are great-- but right now I can't even embed a little vector graphic explaining a function's flow in my source file. Every time I've suggested using a file format that allows things like fonts, styles, embedded images, to write my code, the reaction is always an insanely irrational knee-jerk against it. (Seriously, try…

To prod back, you have three source code files---one is in Word Perfect format from 1987. The second is from Microsoft Word from 1998. The third is an ASCII text file from 1972. Which one can you open and reuse today ?

None of them! The ASCII file might be legible, but then it turns out that you don't have the correct build environment or all the dependencies, so the code isn't useful to you as-is.

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

#248

Earlier quoted context omitted.

Ok, then the problem is more fundamental. If you have always repetitive parts you have a lot of duplication. Duplication is really evil. Please stop using macros without even thinking and instead start thinking how to kill the duplication. That will be much more useful in my experience. Btw I don't think it ever happened in my life that I had to copy up to the second f, and just the thought feels pretty scary..

SQL is just inherently repetitive. What I would do with macros is start with a simple list of column names and turn it into a statement updating them all, or a join, or whatever I needed. Eg. a macro could turn "FirstName" into "a.FirstName = b.FirstName", and then work just as well on "LastName". In other programming I don't have particular favorite macros, but still find small repetitive bits here and there that ca…

The second example that you made is perfect for my point. Why in the world I would possibly want to have 10 different variables, all of them explicitly reinitialised to zero, if I can just write "a = new int[10]" ? (And it is so compact that it doesn't even deserve the indentation to make it verbatim) And if the variables are completely independent then much, much better to use some unit of measure or different objects type or something in the same league to avoid mixing them up and killing your software in the worst possible moment. I honestly can't see how blindingly editing text without any semantic constraint in response to a stream of keystrokes is safer or better compared to what any decent IDE is doing nowadays.. If I'm missing something please explain me what, but I can't really see how it is a more effective way to write software..

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

#249
post #244

Earlier quoted context omitted.

How can it be helpful in the real world? If I want some repetitive behaviour (create new class, generate code) I'll use the IDE behaviour customised to my needs and in the most exotic cases I will add a generating template. But I can't ever imagine myself deleting the selection up to the fourth f from the current cursor position. For me this is not a feature, it's a huge bug because you can delete massive amount of t…

> If I want some repetitive behaviour (create new class, generate code) I'll use the [...] behaviour customised to my needs AKA a function. > code editor is to be context aware and transform your code accordingly to the language rules, not just blindingly execute a series of commands If you "blindingly" execute a series of commands in anything , it's not going to end well. Also, vim can load commands/plugins based on…

A class is certainly not a function, I was speaking about generating valid code in response to a sequence of key strokes / mouse events. If I am building a new module I start with a concrete class and just right click -> extract interface -> select appropriates / all public members and I have a new file with the interface definition. If I am modifying the class I pull the members up to change it. If I just created a new class from scratch I make it inherit the interface, ALT+ENTER and all methods are generated. with the uncountable templates you can do pretty much whatever you want, from generating constructors, creating properties and who knows what else. I have seen people use it live in conferences to generate part of their demo code. All of this is safe and the result compiles correctly apart from the uncommon cases where you need to explicitly ask to make it non compilable.

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

#250

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…

In this age we need to think about things like voice control and 3D manipulation of data-structures and a dynamic view of the code. We can truthfully keep designing 2D editors (and we will always most likely use them to some extent) but I believe it is more important to consider different UI paradigms altogether. For instance, what about editing a living code environment? Game development is very immersive: you can m…

  > We have all the technology.
  > It's time to get to the next level.
Just because you can does not mean you should. Dictating code may be useful is you cannot use your hands, but that's about it. In all other cases there is no benefits of doing that.
Post reply on HN