The aim of this page📝 is to share a small perspective on Vim as a great tool — even if modal and editors dropped modes in the past as modes are not good for "lay people" (non-engineers) with an assertion that tooling matters, and high quality work depends on high quality tools also in knowledge work.
Modal editors are not for everyone, but vim is perfect.
On modality: there's a wonderful talk by Bret Victor about Larry Tesler's crusage against modality in computing (https://youtu.be/PUv66718DII?si=i50uDIjQcofzFzgj&t=2291). He use that as a powerful principle strategically underpinning his effort.
Still, mode-ful vim still here, doing well, and being a superpower of poweruser :)
I consider vim to be a a good tool for high-quality thinking.
Tools does determine thought, tools are cultural expressions
The influence of the tool we are trying to use upon our own thinking habits.
I observe a cultural tradition, which in all probability has its roots in the Renaissance, to ignore this influence, to regard the human mind as the supreme and autonomous master of its artefacts.But if I start to analyse the thinking habits of myself and of my fellow human beings, I come, whether I like it or not, to a completely different conclusion, viz. that the tools we are trying to use and the language or notation we are using to express or record our thoughts, are the major factors determining what we can think or express at all!
https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html
There is a "cultural tradition" that considers the "obsessions with tools" to be amateuristic. But I am more with Adam Jacob of System Initiative on this
where DevOps came from, is a recognition that in order to make the organization scale, we also had to make the automation scale, right? Those two things came together. I think in the early days of DevOps, we tended to talk about it primarily as a cultural thing, as an organizational revelation, if you will, as opposed to a technical thing. We're like, well, there's lots of different tools you could use. They're all roughly going to be good enough to solve this problem. We were wrong. The truth is that it was always both. Culture, the tooling that we choose is the ossification of our culture, basically. There is no separation between what we do every day at work and the culture of our work. It is the same. The movement over time, I think, has grown and changed, primarily as we've both learned more about the tooling, learned more about what works and what doesn't. Then, unfortunately, it's if you look at the outcomes, you feel like the door report and things like that that are surveys of how well we're doing. Most organizations that have adopted these practices, they're certainly better off than they were in 2009, or whatnot. But they land in the mediocre middle. They're like, "We can deploy once a month, or every six months." They have a bunch more automation and tooling. It is better, but they're not living the collaborative dream. [0:05:26] LA: They didn't take the cultural aspects of DevOps and incorporate them into their process. They took the tooling, but not the culture. [0:05:33] AJ: I think they took the culture, and then maybe - I think, maybe they took the culture and the tooling just let them down.
— https://softwareengineeringdaily.com/wp-content/uploads/2024/08/SED1732-System-Initiative.txt
Illustration: Vim is intricate and its registers offer great capabilities.
In normal mode (there's insert, visual, replace, command-line and operator-pending) , you combine one of few operators (d,y,c,g,!) with one of many motions (https://vimhelp.org/motion.txt.html#various-motions)
Let's focus on deletion operation — In vim, d and c are not just deleting — they are cutting, as the removed content is automatically "clipped" (yanked) moved to default register.
If a register is not specified, vim defaults to unnamed register. This is for your default operations not specifying named registers and not doing any advanced edit. Then, there is 10 built-in read-only registers (0-9). These read-only registers are numerical — 0 through 9 — and are your “historical record” registers.
The first of them — register 0 — is special and will always contain the most recently yanked text, but never deleted text; This is handy for performing a yank operation (after deletion still there) + at least one delete operation + and then pasting the text originally yanked with "0p.
The registers 1–9 are for deleted text, with "1 referencing the most recently deleted text, "2 the text deleted before that, and so on up to "9.
To print the content of registers, use :reg command. The types of registers are
Type can be one of:
"c" for |characterwise| text
"l" for |linewise| text
"b" for |blockwise-visual| text
Example
:reg
Type Name Content
UNNAMED
c "" ÄŚINNOSTI V OBLASTI INFORMAÄŚNĂŤCH TECHNOLOGIĂŤ
LAST_YANKED
c "0 ÄŚINNOSTI V OBLASTI INFORMAÄŚNĂŤCH TECHNOLOGIĂŤ
DELETED
l "1 /input/label:LOADER^J
l "2 /input/description:Redshift loader - prod1^J
l "3 /input/uuid:582c77e1-a981-411f-93b0-3313740b256f^J
l "4 /input/ssh_tunnel_enabled:false^J
l "5 /input/ssh_tunnel/local_port:^J
l "6 /input/ssh_tunnel/bastion_user:^J
l "7 /input/ssh_tunnel/bastion_port:22^J
l "8 /input/ssh_tunnel/bastion_host:^J
l "9 /input/database_iam_load_role_arn:^J
Top comments (0)