[Chapter 31] 31.15 Fooling vi into Allowing Complex Macros
Author: Jerry Peek, Tim O'Reilly & Mike Loukides
Date: 1998-08-04T21:46:27Z

#

| Chapter 31 Creating Custom Commands in vi |

## 31.15 Fooling vi into Allowing Complex Macros

vi wants undo to work for macros. Unfortunately, vi's undo is very simple. Rather than allow complex macros to break undo, vi disallows complex macros. I believe this is a big mistake. I'd much rather give up undo than powerful macros.

Fortunately (for those who want real macros), the code that figures out whether a macro will break undo is "very" broken.

For instance, throwing in an `mx` (mark location `x`) at the front of the rhs ["right-hand side" - JP ] of a macro often calms vi down. For some reason, this sends vi through an alternate path on which the macro checking is not as strict.

Likewise, breaking a single macro into multiple macros that call each other can also fool vi. For example, to do one complex macro, I define:

>     map X "bY

and then use:

>     lGkwEX@b

instead of:

>     lGkwE"bY@b

Using `"bY` directly doesn't work, but (on most systems anyway) using the macro `X` does.

So what does it mean that you get the message `can't` `put` `inside` `a` `global/macro`? Probably it means that your UNIX vendor "fixed" vi to recognize that a yank can break undo, even if it's in a called macro.

So rise up. Tell your UNIX vendor that you're tired of being coddled like an MS-DOS user! If you intended to undo that macro, you wouldn't have executed it in the first place. Don't let meddling johnny-come-lately UNIX vendors destroy the venerable screw-the-user tradition that has made UNIX great. Make them put it back the way it was.

- DH

31.14 Don't Lose Important Functions with vi Maps: Use noremap |  | 31.16 vi Macro for Splitting Long Lines