The features demostrated here are almost the exact ones I'm looking to do in Vim (I've only been using for a few months) and the way they describe them here makes them so simple. I hope this continues to mature!
Why Kakoune – The quest for a better code editor
221–230 of 329 posts
Re: Why Kakoune – The quest for a better code editor
#222I'm still waiting for someone to do a modal abstract syntax tree editor. You would only type text when naming something, the other mode would be for navigating the AST.
Sounds like a visual scripting system with low level constructs.
Re: Why Kakoune – The quest for a better code editor
#223Earlier quoted context omitted.
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 muc…
I never thought of it this way, but visual mode essentially does switch vim from verb-object to object-verb.
So in this case...
vtfd
is one more keystroke, but you see what you're deleting before you delete it, so if you need to the next f, you can just smack semicolon until you get there.
vtf;;;;d
(semicolon repeats last "t" or "f" movement)
Re: Why Kakoune – The quest for a better code editor
#224Earlier quoted context omitted.
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…
I agree with saying no. Vim and Emacs will "click" for you when you want to learn them. Wanting to learn them is different than wanting to have learned them. It's the difference between wanting to write a novel and wanting to have written a novel. Personally I would nominate emacs using spacemacs[0], but I knew both already going in. I have a hard time understanding what people find hard about Vim, but I've used it f…
Spacemacs might be great for existing Emacs and vim users, but it is horrible for beginners of both (in my experience), as you can't follow Emacs tutorials, can't follow vim ones, and there just aren't many spacemacs tutorials yet, and several I found were out of date.
Re: Why Kakoune – The quest for a better code editor
#225I'm still waiting for someone to do a modal abstract syntax tree editor. You would only type text when naming something, the other mode would be for navigating the AST.
Have you used paredit-mode in emacs with a lisp dialect? Getting proficient with this mode can be a lot like what you describe. Paredit let's you navigate and edit the tree structure of lisp code pretty effectively. It's not inherently a modal paradigm, but I used it evil-mode successfully. I'd imagine what you describe could be a refinement on that technique. Lisp lends itself well to this type of editing due to it's lack of syntax. Other languages are more difficult.
Re: Why Kakoune – The quest for a better code editor
#226Earlier quoted context omitted.
In vim the only part you need is mmffffy`m. With practice, it's more like finger memory than cognitive load. What he's doing is setting a mark named "m", going to the second "f", and yanking from there back to the mark. It's a fairly interactive sequence as you move the cursor around, so while it looks scary in print, in practice it's just a series of actions you don't think about much. An advantage to using commands…
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 can be turned into temporary macros. Say for example you have ten variables that each need to be reset to zero. Don't type all the resets, just type the variables, turn one of them into a reset while you're recording into macro w, then type 9@w to do the rest.
Copying up to the second f is just a silly example. It could maybe occur though if you were manipulating lines in a data file. You look at it, see that on each line you want to do something with everything up to the second f, so you make a macro. You don't save it for general use.
In short, macros aren't for major repetition that should be factored out, they're for the minor repetitive edits which, if you're not using vim, you might not even think of as repetitive. Sometimes they're useful for refactoring.
So no, I'm not using macros "without even thinking" and this would probably be a more productive discussion if you didn't make such assumptions.
Re: Why Kakoune – The quest for a better code editor
#227Pontificating 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 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
#228This 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…
Not much better. You have to count to find out that 40 number.
Sometimes a mouse is faster.
Re: Why Kakoune – The quest for a better code editor
#229From 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.
Re: Why Kakoune – The quest for a better code editor
#230Earlier quoted context omitted.
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…
Not much better. You have to count to find out that 40 number. Sometimes a mouse is faster.
You can set line numbers in vim to be relative, then there's no counting involved.