The result is that it takes extra taps to produce the string when not at a hardware keyboard. I actually use a suffix character, but my issue remains the same - my choice of character isn’t one that’s quickly accessible from a soft keyboard on iOS. The issue is quick access to the prefix character. It’s one I really need to get around to sorting out as my naming extensions predate iOS and I’m now using them (through TextExpander) daily across Mac, Windows and iOS and it isn’t as efficient as I’d like. Now there’s one final point on this that might be of note to iOS users and I was pleased to hear get a reference in the episode. All trigger strings that I’m very unlikely to come across in day to day text entry. Hence I might choose home, \home, hhome, or xhome for example. Instead this is where a prefix would come into play.īy selecting some character to prefix the string and make it unique enough that it wouldn’t show up accidentally in another word (or in fact any string … sometimes extra care with passwords is required regardless of whether apps support password field security options ). Now whitespace in some text expansion apps can be used to help curtail accidental triggering, but given it could prefix or suffix a larger word, that wouldn’t help here. But it would be terrible as a choice of trigger as there are many words in the English language that use the letters ‘home’ in that order. Now if I wanted to use say home as some sort of trigger for expanding to produce my home address, that would be great for it being easily remembered and being meaningful to me. ![]() It is quite common to use a prefix for text expansion to make that initial trigger string unique. As a result, I’d end up with something like \fooba-looba-dor, and that’s just gibberishīut the point here is to focus on unique string permutations that do not overlap. If I then disable the \foo, I’d next get the ooba expansion triggering when I try to type in \foobar. As soon as I got to the second o, the \foo expansion would trigger and I’d end up with foo-foo-foobar assuming instant expansion (which is honestly rather unlikely on my devices). If I want to define a new text expansion with a trigger string of \foobar, this would never trigger. ![]() \ooba is set to expand to ooba-looba-do.Let’s say I define two text expansion strings: The things to really watch out for is trigger string overlap. If I had a trigger string set as just \, that could potentially be even worse, as I could run the strong risk (options above considered) of triggering an expansion it before I even get to the n. There could be some mitigation here by further restricting a string to be case sensitive, but that’s unlikely to safeguard all potential scenarios. only trigger before, after a whitespace, etc.), then that string is replaced and I lose it. Now if I did have \n set as a trigger then it would be a problem, because as soon as I enter that, along with whatever additional options I may have set (e.g. None of those are \n, so none of those get triggered. If I need to type in a newline code of \n, then as long as I don’t have a snippet trigger string of \n for something else, it will trigger just fine. ![]() To begin with, let’s take a backslash as an initial prefix example. The full trigger string is what is actually important, though there is a factor to consider around the prefix which I’ll come to shortly. Let me try and give an explanation as to why I believe this to be the case. The choice of initial prefix isn’t actually as critical in the ways it is being suggested here. I got aText and used it for 4 years, but now my usage’s gotten more intensive and TE offers just more to justify the change. When I started playing around text expansion, TE was, as for you, a pretty big investment for the use I was going to give it. aText, if you used TE, feels exactly the same (and it even imports all your TE snippets perfectly). Other text expansion apps have their functions, UI, details that make them unique. I just felt bad, as it seems the developer took TE and rewrote a bit to avoid licensing problems, then released the app. It has exactly the same functions, and even a very similar UI. ![]() It’s basically a ripoff of TextExpander.No iOS version, hence no sync or expansion in the iPad and iPhone.My only complaints about it (and the reasons I decided to switch to TE): I don’t know why so few know about the app, as it’s a very complete text expansion app and a very cheap one. It’s actively maintained (not too many functions added over the years, but it has regular updates). It’s basically offering the same functionality than TextExpander without an iOS version for a fraction of the price (4.99$). There is also aText, which I’ve extensively used in the past.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |