How do you record a user macro with vim emulation?

[b]

I finally got around to try to create some simple native SlickEdit macro recordings and ran into a rather annoying snag... there appears to be a conflict between the macro escape and the vim edit mode escape.

Example:
   echo "some text" > somefile

For the above line, if I move the cursor to the end of the > and then start recording a macro (^F11) and then execute the following keystrokes (vim binding)

c$&2<esc>

I should end up (and do) with the following:

   echo "some text" >&2

Unfortunately, that final escape (to exit insertion mode) also terminates and discards the macro. The vim emulation macros work, but aren't listed in the macro facility, so I can't save them for later sessions.  Is there a way to possibly reconfigure the <esc> functionality to discard a macro, record the macro with the exiting of insertion mode and/or a way to save the vim emulation macros across sessions?  Tying the vim emulation macro facilities into the user macro subsystem would be preferred.

SlickEdit Pro 2015 (v20.0.1.2 64-bit)
OS Version: SUSE Linux Enterprise Server 11 (x86_64)

[Clark]

SlickEdit has two kinds of macro recording. There's keystroke recording (VIM emulation only) and source macro recording (on the Macro menu). Source macro recording does not support VIM command mode. That's why when you exit insert mode it cancels. You need to toggle macro recording off while in insert mode if you want to save the source macro recording. It would extremely difficult for source macro recording to work in VIM command mode.

When you use the VIM emulation keyboard recording, it records key stokes. You can save them and name them in the usual VIM way. They are saved and restored as clipboards in "vrestore.slk". It sounds like you want the VIM emulation keyboard recording enhanced to have a GUI more like what is done for source macro recordings. Maybe you want better naming/saving/key binding capabilities. We would have to figure out a way to do this without removing source recording for VIM emulation since it's still needed.

[Clark]

":registers" will list your VIM keyboard macros. The "list-clipboards" command works too.

[b]

Thanks.  I'll continue to play with this.   

I do note that although the clipboards of the macros are saved, once you restart SE, the clipboard of the saved macro is still there, but the binding is not (that is, I can't execute @x to replay the previously saved macro).

[Clark]

Sounds like a bug. When you restart, the keyboard macros are supposed to still work. We will look into this.

[b]

I just confirmed that when you reopen SE and try to paste or replay the named clip board, it will fail.   But if you open the clipboard and then paste the named entry from the GUI, then you can reference the clipboard ("a for example) as well as @a to replay it.

This appears to be the bug.

[Clark]

Seems to work for me. I did a "qq<right><right>q" then exited and did "@q" and it moved the cursor over. I did have to turn on auto-restore of clipboards (Tools>Options>Application Options>Auto Restore). It's off by default (I didn't realize that since my custom config has that option on).

[b]

Tried it again this morning.

Note the screen shots.   I've checked that the clipboards are saved and reloaded in the configuration.
I created a simple vim macro.  Exit SlickEdit and reload it.   When I attempt the macro, I get the error (see attached).   Yet looking at the clipboards, the macro is there (see attached).   When I manually paste that specific named clipboard via the GUI, then the named clipboard/macro magically start working again.

[Clark]

I'll try Ubuntu.  I tested Windows and it works fine.

[b]

I confirmed that it does work as desired on Windows, but fails as I've described on SLES and Fedora x86_64 platforms.   I'd try it on my Mac, but down due to a HD failure.

[Clark]

I won't get a chance to try it today. Let you know tomorrow.

[Clark]

Reproduced. Easy to fix. We a fix out soon for this.

[b]

Great!   Looking forward to it.

[Flunky]

Is this fixed now?

[Clark]

20.0.2 installers were just uploaded. Fix would definitely be in 20.0.2. Not sure if this fix is in 20.0.1 though.