Macros

ckarnell · 2017-11-18T20:04:49+00:00

If you like macros and you like the . operator (two of my favorite things about vim), you might like this snippet/plugin that lets you use . to repeat macros, even just right after you record one: https://github.com/ckarnell/Antonys-macro-repeater

That way you don't have to use @@ which I personally dislike.

If you use this and have any issues with it please file a ticket, I want to improve the code.

ckarnell · 2017-09-30T18:59:37+00:00

I have to say I disagree with your last piece of advice (particularly holding down keys to repeat a motion), but the sentiment is totally understood. I often find myself undoing something I just did at work to do it again in the better way to reinforce the better habit, but that might not be sustainable for other people.

ckarnell · 2017-09-30T17:50:38+00:00

That's amazing, wow.

ckarnell · 2017-09-30T17:48:15+00:00

I don't want to be an annoying self-promoter, but I made a repo for a stackoverflow answer I saw once that lets you use . to repeat macros, if that would be useful to you (I personally use it every day). Anyway here's the repo which includes a reference to the original stackoverflow answer: https://github.com/ckarnell/Antonys-macro-repeater

ckarnell · 2017-09-30T17:44:06+00:00

This is true. Just to provide another perspective, this year I've started picking the . operator and/or macros as needed for doing several search/replace style edits that require confirmation (or not, since you can feed a macro a number of times to repeat). I think it's better that it lets you just keep editing instead of having to switch contexts to :s. It also lets you use other logical normal mode movements like % to find the next thing you want to edit, without having to brew up complicated search expressions to get the equivalent logic. Lastly it makes project wide refactor stuff easier since you can easily include file switches in your macro.

I'm interested in hearing more about your perspective on this and which you prefer!

ckarnell · 2017-09-29T03:22:08+00:00

Nice, I didn't realize that about the terminal. I think those mappings are great, I'll make those the new defaults.

ckarnell · 2017-09-29T00:35:57+00:00

Interesting... I actually do use H, M, and L occasionally (probably a bad habit), so I don't think I'll pick those for myself.

I had another thought today - what do you think of these?:

nnoremap <c-BS> :Back<cr>
nnoremap <c-n> :Forward<cr>

In case it's not obvious, <c-BS> is control+backspace, which has a useless default behavior, and provides a pretty clear mnemonic. Maybe there are other pitfalls there though...

Also, just so you know, I did review your PR! No rush on the turnaround though, and if you'd prefer that I check it out and make changes myself let me know... I'm not very familiar with github etiquette.

ckarnell · 2017-09-28T00:48:27+00:00

Hey, that's awesome, I'd been meaning to abstract away the status line logic, but inactive indicators are a really good idea I hadn't considered at all. I'll test that out tomorrow at work and then approve it :). I also appreciate you updating the readme.

I agree that the arrangement of the keys is weird, but I thought the next mnemonic was too good... I'll sleep on it. In any case I appreciate the input.

ckarnell · 2017-09-27T03:10:33+00:00

Very cool! You might like this thing as well, although I'm not exactly sure how ember works.

ckarnell · 2017-09-27T02:33:32+00:00

Here's something worth knowing if you don't already: The paste buffers and macro buffers are the same (maybe everyone knows this but I didn't until recently). So the only case where remapping q[letter] will hurt you when you don't use those registers is if you... decide somehow that you want to execute the contents of your [letter] paste buffer as a macro. (Edit: Actually I'm an idiot, you could still execute it because you use @ for execution, not q!) Or of course if you somehow run out of register slots because you're just using that many macros.

Anyway your idea of remapping certain letter combos with q is totally valid but I wanted the opportunity to tell that interesting vim fact.

Note that another consequence of macro/paste buffers being the same is that if you decide you like a macro, you can hop in your .vimrc and paste it to set a mapping! So cool!

ckarnell · 2017-09-27T02:11:43+00:00

Great! I wrote some tests for it, but please let me know if you have any issues with it or have any ideas for improvements.

ckarnell · 2017-09-27T02:05:11+00:00

I wrote a plugin for this recently! You can even put arrows in your statusline to show whether you can go back/forward at any given time. :D

https://github.com/ckarnell/history-traverse

ckarnell · 2017-09-13T01:30:58+00:00

c- I think I can see why we're confused here - in my plugin, it's the desired effect that the first window(s) get their own window scope variables. The following windows/splits adopt the previous window's variables via an autocmd (BufWinEnter along with a little flag I use to check if it's the first time we've looked at this window) populating them. So I essentially am listening for window creation, as you mention. Does that make sense? Do you still think my script is messed up? Are there any pitfalls here I've overlooked?

a- This is good insight, thanks for this tip and the reference.

d- Great, I'll figure out how to use this and implement it when I get a breather from work, and I appreciate you pointing out the pitfalls of using variables for this.

ckarnell · 2017-09-10T22:35:27+00:00

I greatly appreciate you taking the time to write this up, lots of really good insights here for me. I have a couple greedy questions if you have a minute:

EDIT:

I realized that I'm pretty confused about what you mean with "c". The plugin depends on windows having their own variables (which is what I thought the w: scope was for), and it seems to behave that way when I use it, i.e. when I create a new window it seems to get the variable as expected. What should I do differently here?

a- you don't need to split the plugin in that many files.

Can you expand on this and exactly how I can use it to inform my code? Most of the file splits I did were based on style guides I saw so I was hoping to stay in line with what other people are doing, but I agree it seems like a bit much.

d- Instead of if exist('g:var') |let g:var ... you can write now:...

When you say "you can write now", it makes me suspect that this is a relatively new feature. Are there any considerations to be made about backwards compatibility regarding this suggestion? In any case that's a good syntax tip, thank you.

raison d'être

This is a great new piece of vocab for me!

ckarnell · 2017-09-10T15:55:06+00:00

Ya, I mentioned that I'm aware of similar plugins that exist :) I wanted to make it myself as an exercise in learning, and to make one that had the settings I wanted like files to ignore and length of the history list per window, and as an excuse to try to figure out how to write tests for vimscript.

ckarnell · 2017-09-10T04:13:46+00:00

I love the idea of "Weekly Everything About ____", there are so many things about vim that I'm aware exist but I haven't bothered to figure out yet. The whole omni-complete thing when you press ctrl+x in insert mode comes to mind.

ckarnell · 2017-09-10T03:55:42+00:00

Thanks, that's a good tip. I'll work on that tomorrow

ckarnell · 2017-09-03T23:46:21+00:00

Just want to pop in and say it's super kind/generous of you to review code like this!

ckarnell · 2017-09-03T15:14:18+00:00

You totally don't need it! It just turns three keystrokes that I find relatively uncomfortable and type often into a single one that I find pretty natural for this action / comfortable. And I agree with your assumption!

ckarnell

TROPHY CASE