I have a macro that, in response to a key sequence (ctrl-U), pastes the following into one of my applications (Mathematica):
UnitConvert[Quantity[, “”/""], “”/""]
As is typical of pasted strings, the cursor ends up at the end. However, to make things quicker, I’d like the cursor to appear just before the first comma, since that’s the first place I need to go to fill in the above template. I.e., after I fill it in, it would look something like this:
Thanks, that works beautifully! [Edit: Turns out this does not work well in Mathematica; see below.] I should, however, mention that I tried it in some of my other macros, and encountered a problem: the cursor went too far backwards, in some cases ending up on the previous line. I’m guessing it was because of the special characters within the pasted text. Specifically, I observed this behavior in each of the following:
Hmm. I wasn’t able to replicate the behavior your describe, but I also can’t test it in Mathematica. That said, if you have a lot of macros like this where you want to insert plain text with pre-defined cursor positions, I’d actually suggest looking into an app specifically designed for snippets and text expansion, like Typinator. When I try your example text in both KM and Typinator, Typinator is quicker to position the cursor after inserting the text, at least in the app I tested it in, so perhaps it will give you better results. If you’re interested, you can find it here: http://www.ergonis.com/products/typinator/index.html
I’ve played with this a bit more, and noticed that:
(a) %|% actually gives me trouble with all the text strings, even the ones I initially thought were working
(b) the problem isn’t precisely that the cursor moves too far to the left; rather it’s that the cursor placement is not consistent–sometimes it goes too far to the left, sometimes not far enough.
I have also noticed inconsistent cursor placement with the L-arrow workaround, but the issue is less common there.
Don’t know if this add’l info. helps diagnose the problem, but figured I’d provide it just in case.
That’s very strange; KM’s cursor insertion may not be as fast as Typinator’s, but it still works reliably for me. Have you tried it in other apps to see if the behavior is consistent across your system, or does this only happen in Mathematica?
Yes, that would seem to be a safe assumption at this point. Unfortunately, without access to Mathematica on my end, there isn’t much I can do to figure out why this is only happening there. The best I can do is to once again suggest trying another app like Typinator that is purpose-made for text insertion and see if it gives you better results.
Since you mentioned Typinator, I tried (with KM) activating the macro in Mathematica with a typed string, “qty”, instead of a hotkey. It didn’t work at all; it replaced “qty” with the letter “v”. I then tried something very simple: paste “hello” in response to the typed string “hl” (no request for cursor placement). Same result: it replaced “hl” with the letter “v”. In Word, there are no issues with either one. So there is something specific to Mathematica that is creating problems with KM. If I decide to try Typinator, I’ll let you know what I find.
Keyboard Maestro implements the %|% very simply by typing the required number of left arrows to get from the end to the location of the token.
So it will work reliably in the normal case, but could fail in any number of cases:
If there are too many arrow keys, the system might lose some from the event queue.
If there are a lot of arrow keys, a badly behaved application might fail to process them all.
If the text includes anything that cannot be arrowed back across (eg return or tab characters that change fields), then the arrow keys will not get you back to where you want to be.
If the application does any text expansion or cursor movement (eg balancing brackets, etc), then the arrow keys will not get you back to where you want to be.
Etc.
Basically, the %|% is exactly equivalent to following the action with N Type a Keystroke Left-Arrow actions, where N is the length of the (processed) text after the %|%.
If that's the case, then why does the macro work much more reliably when I instead enter the needed number of L-arrow keystrokes? I.e., if %|% is misbehaving for one of the reasons you've listed above, why aren't I seeing the same extent of misbehavior when I enter the L-arrow keystrokes explicitly?
Logically, if I'm seeing very different misbehavior with the two alternatives (minor with one and major with the other), that tells me they are not exactly equivalent (e.g., they may implement the same action, but there may be some subtle difference in how the implementation is executed). I look forward to hearing your thoughts on this.
Beats me, the two are essentially identical. The timing might be slightly slower with a sequence of Left Arrows, but not much. That is exactly what Keyboard Maestro does as far as the %|% goes.
Seems like you are getting inconsistent behaviour either way. My guess would be the arrows happening too quickly for the app to handle. You could try manually inserting an appropriate number of option-Left Arrows, since there would be far fewer.
OK, I think I can report more precisely what’s going on:
As I mentioned above, I’m trying to place the cursor within my “Solve” syntax (see above). The macro that uses %|% is activated with CTRL-0, and the one that uses multiple L-arrows is activated with CTRL-S.
I just realized both macros can, in fact, be made to operate consistently, but this requires releasing the CTRL key instantly after hitting the 0 or S. When I do this, the L-arrow macro consistently puts the cursor in the correct place, while the %|% macro consistently puts the cursor 27 positions behind the correct space (which means it backs up onto the previous line). If I don’t release the CTRL key quite quickly enough, the cursor doesn’t go as far back. Thus the inconsistent behavior is due to inconsistency in how long I’ve been holding the CTRL key. Further, I think the reason I was getting more consistent behavior with the L-arrow macro is that, as you said, the timing is slower, so it’s less sensitive to how long I’m holding down the CTRL key. Of course, this doesn’t explain why the macro that uses %|% consistently places the cursor 27 steps to the left of the designated insertion point (when I release CTRL instantly).
If you do the Left Arrows yourself, you can insert a Pause Until Modifiers Control Key is not pressed action to ensure it waits for the control key to be released.
The application is receiving non-control pressed arrow keys, but it would appear it is instead looking at the hardware control key.
OK, I did this (see screenshot). Is that what you had in mind (it took me a bit to figure out how to implement the command you provided, using the pull-down menus; was there a way I could have just inserted it directly)? I'll need to test it more, but it seems to work! What I notice is that the cursor remains at the end of the text string until I release the CTRL key, at which point it moves into place.
Correct me if I'm wrong, but I'm guessing the reason it doesn't work with %|% is because it needs to be inserted between the paste and arrow actions, and using %|% precludes that.
Also could you please explain what this means—I'm not following: "The application is receiving non-control pressed arrow keys, but it would appear it is instead looking at the hardware control key."
And, finally, do you have a fix (or an explanation) for the other problem I mentioned when using KM in Mathematica—namely that, when (instead of activating via a hotkey) I try using KM like a text expander to insert syntax, the action fails completely--regardless of what text I use to call the text expansion, and regardless of what the expanded text is supposed to be, whatever I type turns into a "v" (this is even without any cursor insert). E.g., when it's supposed to simply turn "hl" into "hello", as soon as I type "hl", it turns the hl into a "v".
Also, you can just use a Repeat action with a single arrow key, and then specify the number desired, which would simplify your macro.
Keyboard Maestro simulates events that show the release of the control key, and the arrow keys without the control key being pressed. But the application is probably looking at the hardware state of the modifiers instead of the state of the modifiers in the event.
I would guess Mathematica is seeing the two deletes and processing them, and then seeing the Command-V, and again, ignoring the modifiers and instead seeing just the "v", which is what you are seeing typed.
Possibly you could use Set Clipboard to Text, and then Select Menu Item Edit ➤ Paste.
I'll add that Edit->Paste isn't actually disabled in Mathematica -- it works fine when I try using it normally. The paste also works fine when I click the gear wheel for the paste action in the macro and then click "Try". So it's just disabled when I try activating it with KM.
When I tried the equivalent macro in Word, it worked fine.
