I’m trying to build a macro that toggles LaTeX commands like \textbf{...} around selected text.
The tricky part is that I often only select the inner word, not the whole wrapper.
For example, if I have \textbf{anyword}, I might just select “anyword” — and I want the macro to recognize that it’s already wrapped and remove the \textbf{}.
and If it’s not wrapped, then it should add the wrapper.
I attached a gif showing how it should
So far, I built something that checks %CurrentClipboard%, wraps the text, and pastes it back — but it doesn’t really handle those partial cases. I’d also prefer not to fill up the clipboard history if possible.
I’ve attached a short GIF demonstarting how the macro should behave. I captured it in the Overleaf editor which natively supports this behavior.
But I mainly write in VS Code, and I want to replicate that functionality there using Keyboard Maestro.
Eventually, I’d like to generalize this template so I can create more macros like this for other LaTeX wrappers — e.g. \textit{}, \underline{}, \left(...\right), etc.
Has anyone built something similar? Or have a clean way to detect if the selection is already inside a wrapper?
So you want the KM macro to identify the text around the selected word. We both know it can detect the word that's selected, but can KM easily read the text outside the selected area?
It might be possible for an AppleScript-compatible app, (although I doubt it) but I don't think VS Code is AppleScript-compatible.
But I'm a wiz with Find Image and OCR, and I think I could get a macro that would work most of the time. I can see that your selected text always has a blue box around it, which I could probably find fairly reliably using the KM Find Image action. Then I could probably use another Find Image action to detect if there's a "{" character just before the selected text. And there's a good chance I could also use Find Image to find the red backslash. And then I'm quite sure I could use OCR to get all the text from the backslash to the end of the selected text. I think those are all the pieces that I need to solve this problem.
But let's face it, my approach is not the way anyone should try to solve this problem. Even if my approach worked 99% of the time, it just doesn't feel like the right solution. It would be dependent upon a specific font size, for example.
I like the problem you are trying to solve, but I don't personally have a need for the macro you are proposing. So I'm not inclined to write it.
This kind of thing, where computation needs access both to an immediate selection,
and also to its wider context, depends heavily on the particular editor that you are using.
Only Overleaf (or the browser in which it is running) or VSC, would have access to the selection's wider context, and the ways in which they might access that context won't have much in common.
I took a crack at this because I also write LaTeX in VSCode yet have somehow never before considered such a solution. Unwrapping isn't very pretty or as fast as wrapping, and there are probably cases where it could fail that will require additional actions to handle, but I think it's a decentish starting point.
Fortunately VSCode has very many handy options, and I'm taking advantage of Expand Selection and Shrink Selection in order to check for an existing wrapper. The if-statement is a little weird though because I would expect the following to work, but it doesn't:
Strange, I’ve tested it on a few cases and it worked. Now I’m off the mac, I will check after return.
Maybe during cleaning of macro (a few display text actions were removed and variables renamed) I made the error.
Yes - I made error in name of variable during "cleaning the code". Anyway this wrong named variable is not used in results so the macro is working properly in both cases (adding or removing wrapping text). I don't know what is the practice in this forum - should I correct previous message or should I put new entry with correct form?
Here is the fixed macro - corrected name of one of variables. I also noticed that this macro has small problem where word selected to wrap around is first in row . The reason is strange behavior of Shift Home in VSC, when cursor is in the beginning of line. The space after wrapping } is eaten.
