I moved from Sublime Text to vim. Tried emacs first but for some reason it didn't click. vim was much easier to start with and I see the benefits of mastering modal editing. It's not about typing faster, but developing the muscle memory to transform text without thinking about it. That's really powerful.
Why Kakoune – The quest for a better code editor
211–220 of 329 posts
Re: Why Kakoune – The quest for a better code editor
#212A few questions after playing around with this for a bit:
After making a complicated selection, doing something else, I want to go back to that selection easily. Is there a selection history? A way to execute the last selection?
I tried running a shell command that waited on input and kak hung waiting for the command to finish. is there a way to kill the command? Or better, a way to interact with the command after its running?
I like it so far!
Re: Why Kakoune – The quest for a better code editor
#213Earlier quoted context omitted.
If you aren't sure where you'll end up with, do, in this case mmffffy`m Why would this be better? Because it works in macros too. In vim, you can record it as you go. In vi(nvi), I write it somewhere in the file, basically after I did it once, I would do Ommffffy`m^[0"wDdd and use @W later. You can of course use vim's visual mode, but in this simple case, there's not much difference.
Seriously? What is the advantage of using your cognitive capabilities to write Ommffffy`m^[0"wDdd rather than use a sensible IDE with common refactoring capabilities that are also context aware and integrated with the language you are using?
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 like this is that you can record them into macros with just a couple extra keystrokes as you go. I used to do a lot of SQL and I'd get bored and frustrated, until I learned to use macros in vim to automate the repetitive parts.
Compared to IDEs, why not both? For languages with good IDEs I tend to use them with vim emulators.
Re: Why Kakoune – The quest for a better code editor
#214Earlier quoted context omitted.
Seriously? What is the advantage of using your cognitive capabilities to write Ommffffy`m^[0"wDdd rather than use a sensible IDE with common refactoring capabilities that are also context aware and integrated with the language you are using?
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 text just because your cursor was in the wrong place.
The most important behaviour of a code editor is to be context aware and transform your code accordingly to the language rules, not just blindingly execute a series of commands that edit text generated from "random" key strokes.
Re: Why Kakoune – The quest for a better code editor
#215Earlier quoted context omitted.
> That said I suspect most people would be better off learning a good IDE properly, including but not limited to: To be clear, do you think a "good IDE" is inherently better than Vim/Kako for most people? 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 la…
The core "IDE" features you don't normally get with an editor are things like project views, intellisense, code completion as you type, real time parsing and error highlight, code navigation. Sure you can get most all of this by wrangling plugins for vim (or which ever editor you choose) but in an IDE like eclipse, netbeans, intellij, visual studio, it's all there, ready to go. In effect, a modern IDE is "programming…
Vim and Emacs actually have quite a bit of support out of the box for code development - the ability to follow tags, goto different files, code completion, syntax highlighting, build integrations, etc.
The difference is that IDE-like features Vim are simply tuned for C (add Lisp for Emacs) instead of Java; plugins give them support for other languages. Anyone who has tried to write something other than Java in Eclipse can attest to how much plugin creep starts to enter the fray.
Re: Why Kakoune – The quest for a better code editor
#216I'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.
Re: Why Kakoune – The quest for a better code editor
#217This looks very interesting. But why does this whole site try to use WebM video even on browsers that don't support it? When viewing this site in Safari, there's a bunch of broken videos scattered around.
Re: Why Kakoune – The quest for a better code editor
#218Earlier quoted context omitted.
> Why not stop using the menus then? ;) Because you have to learn more commands/shortcuts than in Vim? ;)
Won't say anything bad about vim, I use it on a daily basis but normal IDEs aren't necessarily as bad as some people seem to want to portray them: A few hints to get reasonably good, fast: Use ctrl+arrowleft/arrowright to jump words at a time. Use shift to select as you move. This works together so ctrl + shift + arrowright means select to the next word boundary. At keast in some IDEs this will also stop at word boun…
A few hints to get reasonably good, fast (in vim):
Use w, W to jump words at a time.
Use v before moving to select as you move.
This works together, so vw will select to the next word boundary.
Press i to insert text, escape to stop inserting text.
Next: in the :help files, you will find a hint that tells you a direct shortcut for that command (like :help quit, or :help write, or just plain :help).
Re: Why Kakoune – The quest for a better code editor
#219Earlier quoted context omitted.
Seriously? What is the advantage of using your cognitive capabilities to write Ommffffy`m^[0"wDdd rather than use a sensible IDE with common refactoring capabilities that are also context aware and integrated with the language you are using?
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..
Re: Why Kakoune – The quest for a better code editor
#220Earlier quoted context omitted.
What would a GUI bring to this that isn't possible in the console? You can use a mouse to issue commands to console programs, after all: if you want to use your mouse to scroll through or select regions of text, you can.
You could use a nicer font, for one.
My console lets me use every font on the system. It even lets me convert variable-width fonts into monospace fonts.
Granted, it won't support using variable-width fonts as-is; but that's never been a problem for me.