Re: Evaluating the cost to type something in vim

On Thu, 24 Jan 2019, Peng Yu <pengyu.ut@gmail.com> wrote:
>> finding the minimal user input that yields a buffer with the input
>> falls under https://en.wikipedia.org/wiki/Code_golf
> This kind of competition is not relevant to what I am not talking
> about. One has to spend extra effort to come up with the absolute
> shortest code. That effort must be considered into the cost as well.
> What I am talking about is "cost", which ultimately map to all
> programmer's time involved in typing and thinking about what to type.
> (But not include thinking about algorithm, data structure, etc.)

Speaking from my own experiences, I use vi and vim differently under
those (increasingly rare, but not never) circumstances where I have a
slow connection. When I can type, say, a half line ahead of where the
system has echoed back my keystrokes, I find myself looking for ways
to optimize the effectiveness of what I type.

If I'm copying something from the line above on a fast connection, I'm
likely to just hit <ctrl-Y> in insert mode a lot. On a slower connection
I'll <esc>ky5f,jpa (as an example, to copy up to the fifth comma).

I'm well aware of the "cost" differences, as you put it. Keeping my
fingers in one location and repeating a single keystroke is very fast
mentally and fairly fast in action on a good system. Over a bad network
link, it's a lot slower because I can't get the immediate visual
feedback. But I have the time to reason out the exact sequence of
movements that will minimize my typing and that increases my effective
speed over the link in two ways: each packet of TCP connection can hold
more response from the server, and I rely on fewer packets sent to the
remote end.

Vi is highly adapted to needs of such slow connection thoughtful
editing. I find the same action optimization skills useful in
constructing macros, too. Explictly separation of searching for a string
anywhere or a character within a line means I can efficiently mix "n"
and ";" searches for finding a matching line and a matching position on
that line (which might not be the start of my match string). Then add in
a "@" action and I can make tail recursive macros easily.

Consider a CSS file with a bunch of inlined images, and other
stuff nearby:

.svg {
background-image:url(data:image/svg+xml;base64,PHN2Zy....)
}
.png {
background-image: url(data:image/png;base64,iVBORw....)
}
.jpg {
background-image:url(data:image/jpeg;base64,/9j/45....); color:#FFF
}
.gif {
border:0;background-image:url(data:image/gif;base64,R0lGOD....)
}

Let's pretend there are zillions of them and we want to replace
all of those with regular https URLs.

First key up a search:
/background-image: *url *(data:
Then find the ( with "f("
Now create a temporary line in the file:
(https://static.example.com/image.png)
And then capture the contents to register c (sans newline):
0"cD
Now reuse that temporary line to write a macro:
n;d%"cp@q
And then capture the contents to register q (sans newline), then
delete the line:
0"qDdd
Finally run the macro with @q

Presto, all instances changed! (And a single 'u' will undo all of the
changes at once.) All because of the same optimizations that help me on
slow links. (And resorting to no vim-isms.)

Elijah

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.