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.
Why Kakoune – The quest for a better code editor
241–250 of 329 posts
Re: Why Kakoune – The quest for a better code editor
#242This 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.
Re: Why Kakoune – The quest for a better code editor
#243From 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.
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
#244Earlier 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…
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
#245If 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…
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
#246Earlier 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 ?
Re: Why Kakoune – The quest for a better code editor
#247Esc Esc : q!
Re: Why Kakoune – The quest for a better code editor
#248Earlier 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…
Re: Why Kakoune – The quest for a better code editor
#249Earlier 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…
Re: Why Kakoune – The quest for a better code editor
#250If 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.