While I prefer to make a script for those kind of tasks (a script could be iterated, reused, produce multiple versions), I really appreciate the example to show the power of vim with commands I already knew!
Yes. I kind of cringe a bit because he learned something very special with a somewhat obscure language. (Fanbois will scream of course).
My goto solution for this kind of task is to open up a jupyter notebook and solve if from there with Python. And yes, repeatability in his solutin is lacking. 3 weeks later with an updated zip file he will have to do it all again.
Are there though? It's a one off specific task. It took 10 minutes to do a bunch of the work whilst making a video/explaining. Writing python for this would feel so uninteractive and clunky. And how would you do the manual part of getting the pdf names? I think you're placing way too much value on repeatability for a specific task. I feel like he'd be done with his task whilst you're still writing your API. Then next week a different professor would ask for a different task and your python script wouldn't work.
> Writing python for this would feel so uninteractive and clunky.
Not if you are in a notebook. Have you tried?
Opening a zip file and retrieving a listing of the file names is also not very difficult in python, what is manual in that?
Apart from the repeatability, a notebook allows you to start from where you failed. With the vim solution, if you do one mistake, I believe you'd have to start over from scratch.
Also if the next professor comes, what I'd do is to make a copy of the notebook and modify it just slightly to make it work for the new use-case.
A notebook is not like starting your IDE, setting up a project and writing some .py files. It is more like reaching for your pocket calculator to do some quick maths.
>>With the vim solution, if you do one mistake, I believe you'd have to start over from scratch.
Execution of a vim macro is atomic and can be undone with 'undo' AND you can edit a vim macro. So the Jupyter notebook solution might be a overkill for what should be a native editor solution.
It's as if he can only program in sed and he can't save the sed scripts. Even if I could learn such complex and arcane syntax, I would surely forget it by the time I need to use it.
True, writing a program for this task is bringing a bazooka to knife fight, but a bazooka is such a terrifying weapon that will make you king of the hood so fast that you will never have to waste time fighting with knives.
There's nothing to forget though. It's just the same regular commands you use when interacting with vim. Same argument applies to doing it in Python that you'd forget the syntax or functions. If you're not gonna forget python, why would you forget common vim commands. To be fair, I have no idea why he used ":norm" instead of putting it in a macro which is a lot more well known and would've done the same thing.
>>I kind of cringe a bit because he learned something very special with a somewhat obscure language.
>>Clever but there are better solutions.
I doubt it.
Because that's not what Macros really are. In a programming language when you want to do X, you go about using programming features such as if-then-else statements and a for loop to achieve it, if things get complicated you use namespace features.
In a Macro you tell the editor to watch what you are doing and repeat it N times. This significantly simplifies your task while you are doing non-trivial manipulation over several buffers/tabs. And in many way this is more easy to do with a tool that supports macros than with a regular programming language.
Mm, i remember doing recording macros in Excel in 1992. I guess it is still possible...
I guess it is fine. just I work regularly with Python so it is more easy for me to remember. For me personally it would be an overhead to learn vim commands. And also the notebooks are more visual for me. I don't need to remember what the last command was, if i am interrupted.
You can iterate & reuse a vim function, and if you use neovim, you can write it in Lua instead of vimscript.
But a script is a totally reasonable approach, and what's important is what works best in your workflow, just pointing out options for the sake of interest.
Heck, Macros are the only reason why you would need vim today. It's really like a programming language with text buffer and chars as your input, and outputs being cursor movements and text.
Everything else something like vscode already provides.
The deal is the kind of text heavy lifting tasks that truly use the power of macros are rare in most modern programming practice. In fact if you are writing repeated patterns of code you are likely doing something very wrong.
Emacs is special in the case that basically all Emacs commands can be automated.
Long back I had written a Twitter thread(Which I now lost), which tried to capture all kinds of editing patterns for you could use macros to go from O(something_crazy) to O(1) equivalent of editing tasks.
>Macros are the only reason why you would need vim today...
I'm a sysadmin, not a rockstar like you coding types. I edit config files, and (lately) edit .csv's for management so excel can show them what they want to see.
My servers are a mix of AIX/RHEL/FreeBSD. I'm stuck with AIX for all the 'important stuff' so usually need to copy the files over to a RHEL box so I can atleast use a modern incarnation of vim over vi.
>>I'm a sysadmin, not a rockstar like you coding types.
We are all the same :) Me started working on Solaris boxes, in fact that's how I learned to use vi well. When all you have is a man page and vi, you tend do RTFM really really well and use it.
Window/pane/buffer management in vscode is childish compared to vim. Vim motions are incomparibly faster than using a mouse. No, vscode doesn't have everything.
I’ll give you the benefit of the doubt. Maybe he was outside recently and forgot to take them off, or perhaps he was about to go out sometime after the video ended.
It's cool if it drags more people into vim, but as a vim user, I'm not very impressed.
I mean, he knows some useful commands (:read, mostly) but the most time saving fraction (repeat xxx times a motion) is very basic and nnot very cleverly executed as he splits it in 2 actions.
Using a macro would have helped introduce a new concept to the new users, while completing the task in one step.
That's odd. I found that the most valuable takeaway from the video is opening the file like he did. I didn't know about norm either. Altogether this was really great and I've been using vim for over a decade.
Vim is so deep that depending on which angle you start your journey with, you might end up with a very different knowledge map than the neighbor, and yet, still feel and be productive.
Thoughtbot took their classes free a couple years ago and I felt a lot more comfortable with vim. All their other classes also seem to integrate vim into the workflow too so you might see them in action.
It's certainly a decent way of doing things, but it's not like if you don't use vim you're gonna sit there clicking around and re-typing the same thing 200 times.
Here's how I'd do it with IntelliJ on my Mac:
* Probably grab the list into my clipboard the same way with ls (pipe output into `pbcopy` then paste into the editor)
* Put an editing carat on each line. Maybe there's a better way but I'd usually select a newline character then Cmd-ctrl-g to select all instances of newline in the file
* Cmd-left to jump to the beginning of the line. Type the <a href=" (which will edit every line) then Cmd-right to jump to the end of the line and finish off the tag. (I feel like this is already faster than the method shown which involved more typing)
* For grabbing the titles of the PDFs, it certainly isn't as flashy but I'd probably just open the folder in Finder, side-by-side it with my editor, and look at the preview that's built into Finder. Cmd+tab to jump focus between the editor and finder to hit the down arrow key to highlight the next document.
Maybe doesn't look as sexy overall, but I don't think it would take any longer than what was shown here. And it doesn't really require me the brainpower of building complicated commands and trying to recall obscure operations like "disown". So it's not really selling me on giving up all my IDE's smarts and facing the daunting learning curve if it's not really gonna save me time.
Actually macros do a lot more than search-replace, including things repeating key strokes across several buffers(tabs in vim). In Emacs you can even have incantations, to open connections to remote servers with tramp etc. Some times things like inserting text after three(or 'n') words etc etc. This can be hard to do by a straight search-replace.
There's a big difference between manipulating text and these sort of tasks.
You will surprised just how many repeated tasks you do without you even knowing you are. At times there are even patterns in places where one things there is total randomness. And many times some people might not be aware that a particular editing pattern saves effort if done through a macro than done manually.
For me, a lot of the value add comes from being able to open up files from a terminal, almost instantly, and make changes way quicker than I would through an IDE. It's also much faster when doing trivial and repetitive changes.
If you're interested you can look up how macros work in Vim. You can automate entire sequences of key strokes which goes beyond 'find and replace'. It's awkward at first but after you master it it becomes second nature and feels like you're working at the speed of thought.
When I have to use an IDE I usually try and install a Vim plugin.
I was thinking similar things while watching the video - my thought was to use column selection mode to create the link tags, though. It's basically the same flow as cmd+ctrl+g to get the new lines.
This is one of many ways of doing this in Vim: you pick the way depending upon the task and what you prefer. Personally I would have used macros in this situation. Recorded my commands and replayed them across the resultant lines. It's actually interesting to see another Vimn user's approach.
Whilst what you're saying is correct about being able to do these things on your IDE/editor, one of the strengths of Vim comes from being able to program edits and then reuse them. I'm always stunned programmers don't naturally get drawn to Vim for this reason alone. And I actually use Vim bindings in my IDEs, giving me the tools from both worlds.
For example, if I made a macro that does all of the edits on a single line, I can replay that macro n times or – better still – play it only on lines that match a regular expression. You can basically describe the edits you want to make either by recording you making them (macro), or – like on this video – by hand constructing them. Either way you can then apply them like a distinct action (procedure) however you want.
Example: `:g/blah/s/a/b/g` will search (g) for all lines matching "blah" then substitute (s) "a" with "b" for all occurrences (g). Similarly `:g/bl.*ah/norm @a` will play my macro in register `a` across all the lines that match the regular expression `bl.*ah`.
Multline edit obvs is good, I find regexp generally better in more complex scenarios. Main problem obvs is getting every non blank line.
The rest of the workflow is ofc what I'd already do, you can do this with any number of tools these days, vim (nor IntelliJ) is not exceptional here...
I'm skeptical about vi/vim but I like to watch videos like these occasionally to see what I'm missing out on. But I lost interest here as soon as he said he was going to avoid using regular expressions. Of course you would use regular expressions to do this task. It makes zero sense to me to commit a bunch of vim -specific tricks to memory instead of practicing regexes which work not only in vim but in almost any decent editor or programming language.
for a task like this, I would often prove it out with regex search and replace in an editor and then if I felt like I was going to need to repeat the task often, turn that into a script
I feel like many people are unnecessarily afraid of regexes but they are a much more broadly useful tool than vim commands
Like he said that was just one technique - he was probably doing it to show viewers something they may not already know, like using a regex. The technique I would use for this is the one that requires the least thinking and the one I usually use in general - record a macro that does one line and moves to the next, and then run it to the bottom.
The video shows some useful techniques but falls a bit flat as vim advocacy for me. Any modern editor (including sublime, vscode, various jetbrain things and of course vim itself with vim-visual-multi) can do this better and more easily with multiple cursors.
Interestingly, although a lot of comments here are "he should have used macros", one thing the video did suggest to me is that maybe I should be using :norm more instead of messing around with macros (which I feel are abominably unergonomic in both vim and emacs).
Because he toggled insert mode, he did somewhat inelegantly use two :norm commands. But you can in fact do it with one. Pressing <C-V> <Esc> to insert a literal esc at the end of the first text insertion, and then typing 'A">++</a>' will work fine.
Serious question: What's with all the meme frogs on the vim video thumbnails on YT? I must be too old to understand the internet, but I thought that was some kind of hipster skinhead thing. Is vim the official text editor of 4chan now?
4chan has a technology board that obsesses over old CLI utilities and stuff less mainstream that they consider to not be “bloat”. So yeah, a vim YouTuber probably is trying to reach out to the 4chan crowd.
Nice! I learned :read, :norm, and maybe considered being a little less averse to creating impromptu commands via map.
I probably would have approached it first by `ls | pbcopy` then putting it in vim, and then using global replace (:s//) to put in the links, then used the Finder's preview (pressing Space in a finder window) to get the PDF file titles, much as he was using that custom map command to work through each file manually.
52 comments
[ 3.3 ms ] story [ 131 ms ] threadMy goto solution for this kind of task is to open up a jupyter notebook and solve if from there with Python. And yes, repeatability in his solutin is lacking. 3 weeks later with an updated zip file he will have to do it all again.
Clever but there are better solutions.
Are there though? It's a one off specific task. It took 10 minutes to do a bunch of the work whilst making a video/explaining. Writing python for this would feel so uninteractive and clunky. And how would you do the manual part of getting the pdf names? I think you're placing way too much value on repeatability for a specific task. I feel like he'd be done with his task whilst you're still writing your API. Then next week a different professor would ask for a different task and your python script wouldn't work.
Not if you are in a notebook. Have you tried?
Opening a zip file and retrieving a listing of the file names is also not very difficult in python, what is manual in that?
Apart from the repeatability, a notebook allows you to start from where you failed. With the vim solution, if you do one mistake, I believe you'd have to start over from scratch.
Also if the next professor comes, what I'd do is to make a copy of the notebook and modify it just slightly to make it work for the new use-case.
A notebook is not like starting your IDE, setting up a project and writing some .py files. It is more like reaching for your pocket calculator to do some quick maths.
Execution of a vim macro is atomic and can be undone with 'undo' AND you can edit a vim macro. So the Jupyter notebook solution might be a overkill for what should be a native editor solution.
True, writing a program for this task is bringing a bazooka to knife fight, but a bazooka is such a terrifying weapon that will make you king of the hood so fast that you will never have to waste time fighting with knives.
>>Clever but there are better solutions.
I doubt it.
Because that's not what Macros really are. In a programming language when you want to do X, you go about using programming features such as if-then-else statements and a for loop to achieve it, if things get complicated you use namespace features.
In a Macro you tell the editor to watch what you are doing and repeat it N times. This significantly simplifies your task while you are doing non-trivial manipulation over several buffers/tabs. And in many way this is more easy to do with a tool that supports macros than with a regular programming language.
I guess it is fine. just I work regularly with Python so it is more easy for me to remember. For me personally it would be an overhead to learn vim commands. And also the notebooks are more visual for me. I don't need to remember what the last command was, if i am interrupted.
But a script is a totally reasonable approach, and what's important is what works best in your workflow, just pointing out options for the sake of interest.
EDIT: for those that don't know:
qa type in some stuff including cr and a return to be beginning of the line
233@a replay macro 233 times.
I did learn a lot of things from the video, but I agree that a macro might have served them better.
Everything else something like vscode already provides.
The deal is the kind of text heavy lifting tasks that truly use the power of macros are rare in most modern programming practice. In fact if you are writing repeated patterns of code you are likely doing something very wrong.
Emacs is special in the case that basically all Emacs commands can be automated.
Long back I had written a Twitter thread(Which I now lost), which tried to capture all kinds of editing patterns for you could use macros to go from O(something_crazy) to O(1) equivalent of editing tasks.
I'm a sysadmin, not a rockstar like you coding types. I edit config files, and (lately) edit .csv's for management so excel can show them what they want to see.
My servers are a mix of AIX/RHEL/FreeBSD. I'm stuck with AIX for all the 'important stuff' so usually need to copy the files over to a RHEL box so I can atleast use a modern incarnation of vim over vi.
We are all the same :) Me started working on Solaris boxes, in fact that's how I learned to use vi well. When all you have is a man page and vi, you tend do RTFM really really well and use it.
vi does support macros. Do try.
I've yet to see vscode get an equivalent for
Being able to slice and dice a buffer with command-line tools is so very, very, very powerful.I mean, he knows some useful commands (:read, mostly) but the most time saving fraction (repeat xxx times a motion) is very basic and nnot very cleverly executed as he splits it in 2 actions.
Using a macro would have helped introduce a new concept to the new users, while completing the task in one step.
Would be an interesting vimgolf exercise though
https://thoughtbot.com/upcase/onramp-to-vim
It's a very simple app and something you can play with during a break but if you can master the 'advanced' sections you will become proficient.
Keep at it! Vim's made me way more productive and saved me countless hours over the years.
Here's how I'd do it with IntelliJ on my Mac:
* Probably grab the list into my clipboard the same way with ls (pipe output into `pbcopy` then paste into the editor)
* Put an editing carat on each line. Maybe there's a better way but I'd usually select a newline character then Cmd-ctrl-g to select all instances of newline in the file
* Cmd-left to jump to the beginning of the line. Type the <a href=" (which will edit every line) then Cmd-right to jump to the end of the line and finish off the tag. (I feel like this is already faster than the method shown which involved more typing)
* For grabbing the titles of the PDFs, it certainly isn't as flashy but I'd probably just open the folder in Finder, side-by-side it with my editor, and look at the preview that's built into Finder. Cmd+tab to jump focus between the editor and finder to hit the down arrow key to highlight the next document.
Maybe doesn't look as sexy overall, but I don't think it would take any longer than what was shown here. And it doesn't really require me the brainpower of building complicated commands and trying to recall obscure operations like "disown". So it's not really selling me on giving up all my IDE's smarts and facing the daunting learning curve if it's not really gonna save me time.
There's a big difference between manipulating text and these sort of tasks.
You will surprised just how many repeated tasks you do without you even knowing you are. At times there are even patterns in places where one things there is total randomness. And many times some people might not be aware that a particular editing pattern saves effort if done through a macro than done manually.
If you're interested you can look up how macros work in Vim. You can automate entire sequences of key strokes which goes beyond 'find and replace'. It's awkward at first but after you master it it becomes second nature and feels like you're working at the speed of thought.
When I have to use an IDE I usually try and install a Vim plugin.
Whilst what you're saying is correct about being able to do these things on your IDE/editor, one of the strengths of Vim comes from being able to program edits and then reuse them. I'm always stunned programmers don't naturally get drawn to Vim for this reason alone. And I actually use Vim bindings in my IDEs, giving me the tools from both worlds.
For example, if I made a macro that does all of the edits on a single line, I can replay that macro n times or – better still – play it only on lines that match a regular expression. You can basically describe the edits you want to make either by recording you making them (macro), or – like on this video – by hand constructing them. Either way you can then apply them like a distinct action (procedure) however you want.
Example: `:g/blah/s/a/b/g` will search (g) for all lines matching "blah" then substitute (s) "a" with "b" for all occurrences (g). Similarly `:g/bl.*ah/norm @a` will play my macro in register `a` across all the lines that match the regular expression `bl.*ah`.
The rest of the workflow is ofc what I'd already do, you can do this with any number of tools these days, vim (nor IntelliJ) is not exceptional here...
for a task like this, I would often prove it out with regex search and replace in an editor and then if I felt like I was going to need to repeat the task often, turn that into a script
I feel like many people are unnecessarily afraid of regexes but they are a much more broadly useful tool than vim commands
Interestingly, although a lot of comments here are "he should have used macros", one thing the video did suggest to me is that maybe I should be using :norm more instead of messing around with macros (which I feel are abominably unergonomic in both vim and emacs).
Because he toggled insert mode, he did somewhat inelegantly use two :norm commands. But you can in fact do it with one. Pressing <C-V> <Esc> to insert a literal esc at the end of the first text insertion, and then typing 'A">++</a>' will work fine.
I probably would have approached it first by `ls | pbcopy` then putting it in vim, and then using global replace (:s//) to put in the links, then used the Finder's preview (pressing Space in a finder window) to get the PDF file titles, much as he was using that custom map command to work through each file manually.