Daniel sent us this one — he's been deep in the text expansion rabbit hole, and he's hitting the wall that every power user eventually hits. You discover these tools, you build up a library of shortcuts — your zip code, your national ID, your templated Alibaba supplier inquiries — and then you realize your snippets are trapped on one machine. He's running Ubuntu, he's got an Android phone, he's moved six times in ten years here in Israel, and every new apartment means updating "myzip" in multiple places. The question is: what's actually good, what's actually cross-platform, and how do you not hand your national ID number to some startup's unencrypted cloud database?
He's right to ask. Most people don't think about text expansion until they've typed the same paragraph for the fifteenth time and their fingers are staging a revolt. But once you start using a snippet manager, the absence of it on another device feels like trying to type with mittens on. The friction is real.
Where do we even start? Because I think a lot of people hear "text expansion" and picture autocorrect with delusions of grandeur. Typing "omw" and getting "on my way." That's not what we're talking about.
Not even close. A real snippet manager is a programmable text injector. It handles multi-line templates, dynamic date insertion, clipboard content, and in the case of something like Espanso, it can even execute shell commands and inject the output. Think about Daniel's Alibaba example — he's not just expanding a word, he's triggering a whole formatted email template with placeholders for supplier name, product specs, and contact details. The difference between autocorrect and a snippet manager is the difference between a sticky note and a mail merge.
That's the complexity axis. Then there's the device coverage axis — single machine versus everywhere you type. And those two axes create the whole landscape of what's useful and what's frustrating.
On one end you've got simple text replacement on a single device. On the other, you've got cross-platform template engines that follow you from your Linux terminal to your Android keyboard. And here's the thing — the utility doesn't scale linearly with device coverage. It scales non-linearly. A snippet that works on your desktop is convenient. A snippet that also fires on your phone when you're standing in line filling out a form on a five-inch screen is transformative. You're not just saving keystrokes, you're avoiding the entire cognitive load of typing structured information with your thumbs.
That's the part that bites. You get spoiled by the desktop experience, then you're on your phone trying to paste a formatted response into some web form and suddenly you're hunting through your notes app for the text you need.
Let's get concrete about what's actually out there. On Linux, the dominant player is Espanso. It's open-source, it runs on Linux, macOS, and Windows, and it's a system-level daemon that intercepts your keystrokes and replaces triggers with expanded text. It's fast, it's configurable via YAML files, and it supports everything from simple word replacement to running Python scripts and injecting the output.
Espanso doesn't have a built-in cloud sync mechanism. If you want your snippets on multiple machines, you're manually setting up a private Git repository or using something like Syncthing to keep your configuration folder in sync across devices. That's not a dealbreaker if you're comfortable with the command line, but for someone who just wants it to work, that's a non-trivial barrier.
The leading open-source option for Linux essentially tells you "sync is a you problem.
And on the other side of the fence, you've got TextExpander — which is basically the brand name in this space. They offer a cloud-synced service with end-to-end encryption claims, a polished interface, team sharing features, the works. But they have no native Linux client. You can use their web app or their API, but there's no system-level daemon for Linux that intercepts keystrokes the way Espanso does. If you're an Ubuntu user, TextExpander is functionally not an option.
The polished cloud solution doesn't support his operating system, and the open-source solution that does support his operating system doesn't sync without a side project. That's already a frustrating Venn diagram.
We haven't even gotten to Android yet. This is where the fragmentation really crystallizes. On Android, you've got Gboard and Microsoft SwiftKey — both have built-in text expansion in their keyboard settings. You can set up shortcuts, type "myzip" and get your address. But those shortcuts are siloed to the keyboard on that device. They don't sync to your desktop, they don't even necessarily sync between different keyboards on the same phone. If you switch from Gboard to SwiftKey, your snippets don't come with you.
Daniel's on Ubuntu, so Gboard sync to Chrome on desktop isn't going to help him either.
Then you've got third-party options like TextExpander's Android keyboard, which does sync with your TextExpander account — but it requires a subscription, it requires you to use their specific keyboard, and critically, it requires the accessibility service permission on Android. That permission lets the keyboard read all on-screen text across all applications. It's a broad permission, and it's a legitimate privacy concern.
You're trading one problem for another. You get cross-device sync, but now you've granted an app the ability to see everything you type and everything displayed on your screen. For a tool that's storing your national ID number and home address.
And this is the fundamental tension. The technical mechanism that makes text expansion work — intercepting keystrokes and injecting text — requires deep system access. On Linux, Espanso hooks into the X11 or Wayland input system. On Android, it's the accessibility service. On macOS, it's the Accessibility API. Each operating system has a different security model, a different input architecture, and different restrictions on what third-party apps can do.
The reason no single tool covers Linux, Windows, macOS, and Android seamlessly isn't just that nobody's bothered to build it. It's that each platform requires a fundamentally different integration approach, and maintaining all four is a massive engineering burden.
And the market is small enough that most companies pick their battles. aText covers macOS and Windows only — it's a one-time purchase, which is nice, but its sync goes through iCloud or Dropbox, neither of which offers end-to-end encryption. No Linux, no Android. PhraseExpress covers Windows and has a limited macOS client, but no Linux and no Android. It does offer a local-only database option, which is interesting from a security perspective — your snippets never leave your machine — but you sacrifice sync entirely.
The "holy grail" of one tool everywhere doesn't exist as of mid-twenty-twenty-six. What you get instead is a multi-tool compromise or a feature gap you just live with.
That multi-tool reality is exactly what Daniel described without naming it. He's got something on Ubuntu, probably Espanso, and he's got something separate on Android, probably Gboard's built-in dictionary. When he moves apartments, he updates "myzip" in two places. When he forgets to update one of them, he fills out a form with his old zip code and gets a delivery sent to his previous address.
Which has happened to me. More than once. You'd think I'd learn.
The "myzip" example is actually perfect for illustrating why sync matters. It's a tiny piece of data — five to seven digits — but it's used across dozens of contexts. Government websites, utility bills, online orders, shipping forms, banking. Every time you move, you have a window where some system still has your old address, and every form you fill out manually is a chance to typo the new one. A synced snippet solves that. You update it once, and every device pulls the new value.
That's the low-hanging fruit. The Alibaba template is where you see the real power. Daniel mentioned he's sourcing a product — so he's probably sending the same structured inquiry to a dozen suppliers. "Dear supplier name, I am interested in product with specs, please provide MOQ and pricing to my email." That's a multi-line template with multiple fields to fill in per message. Typing that on a phone is genuinely painful. Triggering it with a shortcut like "semicolon alibaba" is almost magical.
You can get even more sophisticated. With Espanso, you can set up form templates — the snippet triggers, and a dialog box pops up asking you to fill in the supplier name, the product, the specs, and then it assembles the email with all the fields populated. You're not just saving keystrokes, you're eliminating the mental overhead of remembering the template structure each time.
That's the part I think people underestimate. It's not just about typing speed. It's about not having to hold the structure of a multi-part message in your head while you compose it. The snippet manager becomes externalized memory for your communication patterns.
Which brings us to the elephant in the room. These tools are handling your most sensitive personal data. National ID numbers, home addresses, phone numbers, email templates that might contain confidential information. And the security models vary wildly across the ecosystem.
Let's go through the real risks. If I store my national ID in a text expander, what am I actually exposing myself to?
It depends entirely on the tool and how you've configured it. With Espanso, your snippets live in YAML files on your local filesystem. If your disk is encrypted — which it should be — those files are protected at rest. But they're plaintext on disk while the machine is running. If someone gains access to your user account, they can read every snippet. There's no additional encryption layer within Espanso itself.
It's as secure as the machine it's on.
With TextExpander, they claim end-to-end encryption for cloud sync. Your snippets are encrypted before they leave your device and decrypted only on your other devices. In theory, TextExpander the company cannot read your snippets. But — and this is a significant but — verifying that claim requires trusting their implementation. You can't independently audit it because the client isn't open-source. You're taking their word that the encryption is applied correctly and consistently.
The Android keyboard with accessibility service access adds another layer of concern. Even if the sync is encrypted, the keyboard itself can read everything on your screen. That's a lot of trust to place in a single app.
PhraseExpress takes a different approach entirely. Their local-only database option means your snippets never leave your machine, period. No sync, no cloud, no transmission. That's more secure by default because there's no attack surface for a data breach. But you lose cross-device functionality entirely. It's secure because it does less.
The security landscape is a trade-off between convenience and exposure. Local-only is more secure but less useful. Cloud-synced is more useful but introduces transmission and storage risks. And the tools that claim to bridge that gap with encryption are asking you to trust their implementation without independent verification.
There's another dimension to this that nobody talks about until it's too late: vendor lock-in. If you build a library of two hundred snippets in TextExpander over three years, migrating to aText or Espanso is painful. Most tools offer CSV or JSON export, but the field mappings rarely align. TextExpander might store your snippets with fields labeled "abbreviation" and "content" while Espanso uses "trigger" and "replace." It sounds trivial, but when you have hundreds of snippets with nested formatting, variables, and special characters, a simple find-and-replace on the export file doesn't cut it.
You end up in what you might call a snippet jail. You stay with a subpar tool not because it's good, but because leaving means hours of manual migration and testing.
This is where the open-source tools have a structural advantage. Espanso's configuration is just YAML files in a folder. You can version-control them with Git, back them up anywhere, and migrate them to any other tool that can parse YAML. The format is transparent and documented. You're not locked in because you own the data format.
If you're building a snippet library from scratch and you care about future-proofing, the advice is: prefer tools that store your data in open, documented formats on your own filesystem.
That's the principle. And it connects to a broader trend we're seeing — the bifurcation of the market into "convenience cloud" and "privacy local." TextExpander and PhraseExpress represent the convenience cloud model: polished, synced, subscription-based, and opaque. Espanso and aText with manual sync represent the privacy local model: more setup, more control, open formats, and no third-party server holding your data.
The bifurcation maps roughly to technical skill. The convenience cloud tools are designed for people who want to install and forget. The privacy local tools assume you're comfortable with a config file and a sync mechanism you manage yourself.
Which is why Daniel's situation — Ubuntu user, technical enough to be sourcing on Alibaba, but frustrated by the sync gap — is exactly the persona caught in the middle. He's not afraid of a config file, but he also doesn't want to maintain a private Git repo just to keep his zip code in sync.
Let's talk practical solutions. If you're in his position — Linux desktop, Android phone, security-conscious — what's the best current compromise?
I'd say the strongest option is Espanso on the desktop side — Linux, Windows, and macOS all covered — with manual sync via a private GitHub repo or Syncthing. Syncthing is actually the smoother option for this use case because it's continuous and peer-to-peer. You set it up once, point it at your Espanso config folder, and every change propagates to your other machines within seconds. No servers, no subscriptions, your data never leaves your control.
That's where you accept the compromise. There's no Espanso for Android, and there likely never will be given the architectural differences. So you either use Gboard's built-in dictionary for a small set of non-sensitive snippets — your zip code, a few common phrases — or you use a dedicated snippet keyboard for Android and keep the library intentionally minimal. The key is to not put anything sensitive in the Android snippets that you wouldn't want accessible through a keyboard app.
You segment your snippets by sensitivity. National ID stays on the desktop, handled by Espanso. Zip code and common email templates go on both, but through different tools with different security postures.
And this connects to a broader principle: use the right tool for the sensitivity level. For passwords and credit card numbers, use a dedicated password manager with form-fill capabilities. Password managers are optimized for filling username and password fields on web forms — they understand field types, they match against domains, and they have security models designed specifically for secrets. A text expander is not a password manager, and treating it like one is a mistake.
That's an important distinction. A password manager fills form fields. A text expander injects arbitrary text into any text context — a code editor, an email body, a forum post, a terminal. The use cases overlap but the security requirements are different.
The misconception I see constantly is people thinking "I'll just put everything in my password manager." But password managers are terrible at injecting boilerplate text into arbitrary contexts. They're not designed to expand a trigger word into a multi-paragraph email template while you're composing in Gmail. They're designed to recognize a login form and fill two fields. Using a password manager for text expansion is like using a scalpel as a butter knife — it technically works, but you're misusing the tool and you'll be frustrated.
The clean separation is: secrets go in the password manager, boilerplate goes in the text expander, and never the twain shall meet.
That's the framework. And the third bucket — the one Daniel's Alibaba template falls into — is dynamic templates. These aren't secrets and they're not static boilerplate. They're structured text with variables that change each time. That's where a real snippet manager shines and where neither autocorrect nor a password manager can help you.
Let's talk about where this is all heading, because the landscape isn't static. We've got AI writing assistants becoming more integrated into operating systems — Grammarly, Copilot, whatever Apple's cooking up. The line between "text expansion" and "AI autocomplete" is starting to blur.
It's already blurring. Think about what Gmail's Smart Compose does — it predicts the next phrase you're likely to type based on context. That's text expansion without the trigger word. It's probabilistic rather than rule-based. And as these models get smaller and more efficient, you can imagine a local language model running on your device that learns your common responses and offers them contextually without you ever defining a snippet.
The snippet manager of twenty-thirty might just be a fine-tuned local LLM that watches what you type and says "you're about to send another Alibaba inquiry, here's the template.
That raises its own set of questions. If the model is generating your text, where does the template live? Is it a rule you defined, or a pattern the model inferred? Can you edit it explicitly, or do you have to retrain the model? The transparency and control of explicit snippets — you wrote the trigger, you wrote the expansion, you know exactly what will happen — that's a real value that probabilistic systems don't easily replicate.
There's something appealing about the determinism of a snippet. You type the trigger, you get the text. No hallucination, no creative reinterpretation, no model deciding your inquiry email would sound better with a different tone. It's programming in miniature.
That's exactly the right way to think about it. Each snippet is a tiny program. The trigger is the function name, the expansion is the body, and the snippet manager is the runtime. And like any programming environment, you want portability, version control, and a clear understanding of what executes when.
If someone listening wants to get started — or wants to fix the fragmented mess they're currently in — what's the practical path?
Step one: audit your own typing. Spend a week paying attention to what you type repeatedly. Your address, your email, your phone number, your national ID, a few common sentences you use in customer service emails or forum responses. Identify your top five to ten most-repeated text inputs. If you don't have a snippet for each, you're leaking time.
Start with a single-device tool on your primary machine. If you're on Linux, that's Espanso. If you're on Mac, aText or Espanso. If you're on Windows, Espanso or PhraseExpress. Get comfortable with the workflow — defining triggers, testing expansions, building the muscle memory of using them — before you worry about cross-device sync. Most people never get past this step, and even single-device text expansion is a massive productivity win.
Build the habit first, then scale the infrastructure.
Step three: once you've got a library of snippets you actually use, then decide whether cross-device sync is worth the trade-offs. If you need it, set up Syncthing or a private Git repo for Espanso. If you're in the Apple ecosystem and value convenience over control, TextExpander's subscription might be worth it. If you're on Android, accept that you'll have a separate, smaller snippet library there and keep it non-sensitive.
The security rule to tattoo on your brain: national ID numbers, passport numbers, and anything that would ruin your life if leaked — those go in a password manager's secure notes or form-fill, not in a text expander's plaintext config file.
That's the clean separation of concerns. Your text expander handles the friction of repetitive communication. Your password manager handles the security of secrets. Each tool does what it's optimized for, and you don't cross the streams.
Which leaves us with the open question. Will we ever see a truly open, cross-platform, end-to-end encrypted snippet manager that works on Linux, Windows, macOS, and Android without requiring a computer science degree to configure? Or is the fragmentation inherent — baked into the different operating system architectures in a way that no single tool can paper over?
I think the fragmentation is structural. Each platform's input system, security model, and developer APIs are different enough that maintaining feature parity across all four is a monumental engineering challenge. And the market of people who actively use all four platforms and care deeply about text expansion is small. The economic incentive to solve this perfectly just isn't there.
We live in the multi-tool world and manage the seams ourselves.
But the AI integration angle might change the calculus. If operating systems start building context-aware text suggestion directly into the input layer — not as a separate app, but as a system service — then the fragmentation problem goes away because the platform owner handles it. You'd get cross-device sync through your OS account, not through a third-party tool.
Which is convenient and also terrifying, depending on how you feel about your OS vendor having a complete log of everything you type.
That's the trade-off we keep making, isn't it? Convenience now, questions later. At least with a self-managed Espanso setup, you know exactly where your data lives and who can access it.
The sloth approach. Slow to set up, deliberate, but you know what's happening under the hood.
The donkey approach is to read all the documentation, compare every option, and still end up with three different tools for three different platforms.
We contain multitudes.
We contain snippets.
And now: Hilbert's daily fun fact.
Hilbert: The largest Hanseatic trading post in Somaliland during the late Victorian period was a single warehouse in Berbera, leased by a Hamburg merchant in eighteen ninety-one for an annual rent of two Maria Theresa thalers — a currency that had been out of production for forty years but remained the preferred silver coin across the Horn of Africa.
That's less than I spend on leaves in a week.
I have so many follow-up questions and I know none of them will be answered.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for making this show happen and for whatever research rabbit hole produced that fact. If you enjoyed this episode, do us a favor and leave a review wherever you listen — it helps other people find the show. We'll be back soon with more questions from Daniel and more answers that probably raise more questions than they resolve.
