If you just replace 'd' with 'y', though, the example is a good one: hitting period would just yank the same thing again.

Edit: the yank example is actually way better, because you don't find out that you did something wrong until you go off and paste it somewhere else.

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.

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.

Sure, I thought of that. Then instead of a variable named "salary" you've obfuscated your code by calling it a[4].

Ah, but you can just name your indexes, so it's a[salary]. But now you've got ten lines of code naming each of the index values, and a vim macro makes it faster to write again.

In any case, macros are just one of the features that make vim productive. I find that I do a lot more small refactors when I'm using an editor that makes arbitrary edits really fast and convenient. It's complementary to the named refactorings you have in an IDE. If all you're doing is pointing and clicking then you don't need vim, but if you're actually writing code, it helps.

I used to use a vim emulator in Visual Studio, and it was great. Now I'm working with stuff that doesn't have IDE support, and I'm still productive.

A lot of good programmers are hooked on vim. Hasn't it occurred to you that maybe they have good reasons for that?

Or as I suggested earlier you just use objects instead of random variables.

    employee = new Employee();

And you have all the fields reinitialized to the correct default value (that can be different from zero) and much better naming because now you can tell the difference between employee.Username and user.Username

Sure, and I do that when I can (e.g. not when I'm writing SQL), but the point of my quick examples isn't to show off my software engineering, but to illustrate what vim can do in the simplest way I can think of.

I guess I'm failing to make the point, so I'll just refer to the articles that got me to try it in the first place.

http://www.viemu.com/a-why-vi-vim.html

http://www.moolenaar.net/habits.html

Have you seriously never ran into a situation where your IDE does almost what you want, but you still have to do some bit of it manually just because IDE can't handle this specific thing or format or whatever? If so you are either spending way more time thinking about your architecture and code before writing anything than most people or your IDE is fucking amazing.

While remembering long button combinations seems hard and tedious and "strain on cognitive capabilites" they really are just chained commands. In the idea world you don't think: "now I just have to hit v4w"+y to copy these things to clip board", but instead: "I'll copy next four words into clip board" and then just execute the commands. Same goes to longer commands, instead of hunting down some hidden feature in your IDE, you can just bang out chain of commands you wish to execute.

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

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.

If it goes wrong, just hit u to undo.

nvi is not Vi; it's a fork of Elvis: another Vi clone, like Vim.

Vim is older than Elvis, by years.

The FOSS BSD derivatives never got the actual Vi editor of Bill Joy ancestry.

Wikipedia has Elvis predating Vim by nearly 2 years (January 1990 vs. November 1991).

While nvi isn't vi, it was intended to be "bug-for-bug compatible" with Joy's original vi. It's not quite there, but it is much closer than any of the other vi clones.

The FOSS BSD derivatives can have a vi descended from Joy's: `2bsd-vi` in FreeBSD's ports collection, `traditional-vi` in OpenBSD's ports collection, `ex` in NetBSD's pkgsrc collection. Or anyone can nab it from http://ex-vi.sf.net/ ;)

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)

The dot trick is fine, unless you wanted to paste the deleted text somewhere afterward, in which case you need to pick it up in one go.

Otherwise, yeah, dot is great. I love using that for repetitive stuff on "tabular" copied entries that I'm not thinking real hard about transforming. (E.g. - 5 lines or so that I'm not cooking up a regex or an perl/awk spell to transmute)

   > The dot trick is fine, unless you wanted to paste the 
   > deleted text somewhere afterward, in which case you 
   > need to pick it up in one go.

No.

   "1p.

You got me. I don't know how to parse that ("1p.).

My ignorance is showing. Is there a stack of yank buffers??? Does this p-for-put pop the top buffer, back up before the inserted text, then .-do-it-again and put the delete/yank beneath the last one on the stack? I have no idea what the quotation mark actually does.

Thanks in advance if you can explain how that works to me.

You can be sure that the Kakoune authors are familiar with vi(m).

Having said that, if you like both vi(m) and the structural regular expression support of sam/acme you might be interested in vis which combines the two:

https://github.com/martanne/vis

>I just wish you guys can learn more of vi, so you can truly deliver something better. So far, these surface scratching alterations only build on irritations of those vi first-timers

Mind expanding on that, or are you just going to whine? It's not like vi is the ultimate tool.