Suggestion: be more positive about text expansion in KM

Questions & Suggestions
1

I suppose the wording of the title of this topic is aimed at @peternlewis but I mean it not to be confrontational but rather to sound encouraging about KM’s capabilities when it comes to text expansion—as the basis for an open discussion.

Years ago I used aText (I forget now why I stopped) and for a long time I used Alfred and KM for text expansion. A while ago I was won over to Espanso and for the most part really like it, but it has some deficiencies which I do not think will be dealt with in the near future.

Recently I switched to Typinator, which seems to be the #1 choice among KM forum members, and it’s good of course (although I do not like the interface much), but I still use the typed string trigger in Keyboard Maestro for certain purposes: (1) for triggering macros that do more than just expand text[1]; (2) for such nice tricks as the conflict palette so that I can use the same typed string trigger for different results and select from the alternatives.

So... there is still a lot to be said for KM’s text expansion capabilities. So, why do KM users also use a separate text expander application? As I recall, the issues are:

(1) Having lots of text expansions in KM swells its database further, which is a Bad Thing (for some reason).

(2) Various bells and whistles in text expander applications (I forget what, so they cannot be important to me!).

(3) You cannot use KM to expand text in certain parts of KM itself (e.g. execute macro by name).

(4) You cannot, of course, use KM to expand text if the KM Engine is not running, and you might need that for some reason.

(5) It is relatively cumbersome to set up simple text expansions in KM.

Points (3) and (4) can be addressed by using a dedicated text expander application for those situations.

Point (2): er... remind me.

Point (1)—the wish to avoid adding too much to KM’s database—has, if I recall correctly, been mentioned quite often. Would the answer not be to move the text expansion data out of the main KM database? Does it, for technical reasons, have to be housed with the other data?

Point (5)—the interface—might perhaps be related to Point (1). I really like the way Espanso just has a list of expansions stored in a .yml file[2]. It’s easy to edit, and, being plain text, it’s easy to hack around with using KM macros or whatever you want to use. Such an interface (if you one can even call it that) will of course not be too everyone’s taste, but the point is that you do not need to get fancy with the UI to have a workable solution for quick creation of text expansion snippets.

Propositions:

  • KM works well as text expander, and offers some unique capabilities.

  • KM would be used more as a text expander (by existing and potential users) if creation of text expansion snippets were easier.[3]

  • Positioning KM as primarily a text expansion product is definitely not what I am suggesting, but given how able KM is in connection with typed text triggers, it would be good to see text expansion in KM break through some of its current limitations or deficiencies, which are not—at least for points (1) and (5)—anything other than self-imposed or, I should say, the consequence of technical history and… conceptual models?

Thanks for reading all that, and, in advance, for correcting my thinking where it is wrong!

  1. Yes, Typinator can do more than just expand text too. ↩︎

  2. Or in more than one yml file if you get fancy. ↩︎

  3. Hmm, I should check whether someone has provided such a macro in this forum somewhere. However, I am talking here about KM’s built-in features. ↩︎

4 Likes
2

Search the forum using "text expan @peternlewis" for help with this...

And don't forget @mrpasini's Brevis

2 Likes
3

As @tiffle mentions, the Keyboard Maestro Brevis tries to address some of your points. I've been using it since I wrote it to handle 78 expansions of various types. None of them are in Keyboard Maestro's plist.

You're referring to the size of the plist. And I discuss this issue in the Brevis documentation. But the short version is that the Brevis expansions are all stored in one variable, which can be easily backed up, shared and restored using the Control Panel.

So the size of your plist isn't affected by your expansions.

In the years I've been using Brevis, I've very very rarely felt the need to edit an expansion so the Control Panel does not include that option. It's rare enough that deleting the problem expansion and redefining it (no matter how long or complicated) is easy.

That's in part because Peter wrote a macro to create an expansion from a selection that Brevis uses. So in Brevis you only have to select something, call up the Create From Selection macro, pick a typed string to call the expansion and a category to store it in (because it can be hard to remember these things) and you're done.

I'll add one thing Brevis does that I don't think the commercial products do. It allows either pasting or typing the expansion depending on how the expansion is initiated. This turns out to be very helpful in applications that struggle with the faster pasting (like InDesign).

Anyway, more in the documentation (including support for tokens).

4 Likes
4

Thank you @mrpasini and @tiffle for reminding me about Brevis! It had indeed slipped my mind.[1]

  1. What a Butt-head, eh? ↩︎

1 Like