guides

Migrer de la configuration YAML d'Espanso vers un correcteur d'expansion de texte GUI

Par Équipe Lightning Assist14 septembre 20269 min de lecture
espansoyamlmigrationguitext-expanderlinuxwindowsmacos
Partager :
Migrer de la configuration YAML d'Espanso vers un correcteur d'expansion de texte GUI

Réponse rapide : Espanso stocke chaque snippet comme une paire trigger/replace dans des fichiers YAML de correspondance (~/.config/espanso/match/*.yml), ce qui signifie qu’ajouter ou modifier un snippet implique d’ouvrir un éditeur de texte, de respecter la syntaxe YAML et de redémarrer le service pour tester. Migrer vers un text expander GUI comme Lightning Assist transforme chaque correspondance en snippet dans un éditeur visuel — même texte déclencheur, même remplacement, mais un champ de formulaire au lieu d’un fichier. Depuis Lightning Assist 2.6, les fichiers de correspondance peuvent être importés directement : sélectionnez le .yml, et chaque paire trigger/replace devient un snippet, avec {{date}}, {{clipboard}} et les variables de formulaire converties en placeholders. Seuls les déclencheurs shell-command et regex nécessitent encore une vérification manuelle.

Transparence : nous développons Lightning Assist, un expanseur de texte payant — Espanso est donc un concurrent. Espanso est gratuit et open source, et chaque correctif ci-dessous concerne Espanso lui-même : aucun n'exige de changer d'outil.

Si vous n'avez jamais ouvert ~/.config/espanso/match/base.yml, rien de tout cela ne vous parlera, et c'est exactement le public visé par ce guide : des personnes qui ont réussi à faire fonctionner Espanso, ajouté une dizaine de snippets, et se demandent maintenant s'il existe une version de tout ça où elles n'ont pas du tout à réfléchir au YAML.

Pourquoi la configuration YAML d'Espanso devient une source de friction

Espanso est un outil réellement bien conçu. Il est gratuit, open source, multiplateforme, et son modèle basé sur des fichiers est un choix de conception délibéré, pas un oubli — YAML est portable, permet les diffs, et est scriptable. La friction apparaît plus tard, une fois que vous l'utilisez vraiment au quotidien :

Des fichiers de correspondances éparpillés dans votre système de fichiers. Espanso organise la configuration en un dossier match/ (quoi développer) et un dossier config/ (comment l'expansion se comporte), en partant de match/base.yml. À mesure que votre nombre de snippets augmente, soit vous continuez à ajouter à ce fichier unique, soit vous commencez à diviser en plusieurs fichiers .yml — dans les deux cas, retrouver « celui sur les tarifs » six mois plus tard signifie ouvrir des fichiers et les parcourir, car il n'y a pas de barre de recherche.

L'indentation, c'est la syntaxe. Une correspondance basique ressemble à ceci :

matches:
  - trigger: ":br"
    replace: "Best Regards,\nJon Snow"

La documentation d'Espanso elle-même est directe à ce sujet : "Make sure to include the indentation, otherwise it won't be valid YAML syntax." C'est très bien pour un développeur à l'aise dans un éditeur de texte, et c'est exactement le genre de chose qui casse silencieusement quand vous collez un snippet depuis Slack, ou copiez un bloc multi-lignes et que les espaces ne suivent pas. En général, vous vous en rendez compte parce que le déclencheur ne s'expand tout simplement pas — pas de boîte de dialogue, pas de soulignement rouge, juste un snippet qui ne fait silencieusement rien jusqu'à ce que vous partiez à la chasse à un espace égaré.

Pas de synchronisation, pas d'équipe. Espanso stocke tout localement par conception — ce qui est réellement bon pour la confidentialité, mais signifie que faire passer vos snippets sur une seconde machine demande une copie manuelle de fichiers, un dossier Dropbox, ou un dépôt git personnel que vous maintenez vous-même. Il n'y a pas de compte, pas de synchronisation multi-appareils intégrée, et aucun moyen de transmettre votre bibliothèque de snippets à un collègue autrement qu'en lui envoyant les fichiers .yml en lui demandant de les placer dans le bon dossier.

Redémarrer pour tester. Modifier un fichier de correspondances et confirmer que ça a fonctionné signifie généralement : enregistrer, revenir à l'application dans laquelle vous testez, taper le déclencheur et, si rien ne se passe, retourner vérifier le fichier. C'est une boucle courte, mais une boucle que vous répétez à chaque modification, indéfiniment.

Rien de tout cela ne fait d'Espanso un mauvais logiciel. Cela en fait un logiciel conçu pour des personnes à l'aise avec l'idée de traiter la configuration comme du code. Si ce n'est pas ainsi que vous voulez passer votre temps, une interface graphique (GUI) est la solution — pas un « meilleur » éditeur YAML.

À quoi ressemble réellement l'équivalent GUI

Dans un correcteur d'expansion de texte GUI, un snippet est une ligne, pas un fichier. Vous ouvrez un panneau (dans Lightning Assist, il s'appelle « My Snippets »), cliquez sur « Create Snippet », tapez le déclencheur dans un champ et l'expansion dans un autre, puis enregistrez. Il n'y a aucun fichier à localiser, aucun service à redémarrer, et aucune indentation à respecter, parce qu'il n'y a pas d'indentation — le texte enrichi, le formatage HTML et le contenu multi-lignes se tapent ou se collent directement dans le champ d'expansion, sans échappement requis. Les snippets sont organisés dans des dossiers que vous nommez vous-même, et vous pouvez faire une recherche dans toute votre bibliothèque au lieu de parcourir des fichiers.

Le compromis est celui auquel on pourrait s'attendre : vous renoncez à l'accès direct aux fichiers (pas de diff git sur l'historique de vos snippets, pas d'édition dans Vim) en échange de ne plus avoir besoin de toute la mécanique YAML dès le départ.

Espanso → Lightning Assist : correspondance des concepts

Si vous pensez déjà dans le vocabulaire d'Espanso, voici comment chaque élément se transpose :

Concept Espanso En YAML Équivalent GUI
Match Une entrée sous matches: dans un fichier .yml Un snippet — une ligne dans le panneau Snippets
Trigger trigger: ":br" Le champ Trigger — tapez directement la même abréviation, aucun deux-points requis sauf si vous voulez le conserver
Replace replace: "Best Regards,\nJon Snow" Le texte d'expansion du snippet — texte enrichi, HTML et contenu multi-lignes pris en charge nativement
Vars / extensions (date, shell, presse-papiers, formulaire) Un bloc vars: référençant un type de variable Espaces réservés insérés dans l'expansion — [#Date#] et [#Name#]
Fichiers de correspondances (base.yml, .yml personnalisés) Fichiers dans ~/.config/espanso/match/ Dossiers dans le panneau Snippets — organisation visuelle plutôt que par nom de fichier
Reload / espanso restart Redémarrage manuel du service pour prendre en compte les changements Rien à faire — les snippets sont actifs dès l'enregistrement
Déclencheurs regex, correspondances par commande shell YAML + scripting, spécifique à Espanso Non reproduit. Si c'est central dans votre flux de travail, restez sur Espanso pour ces cas

Cette dernière ligne compte : ceci est un guide de migration, pas une affirmation que « Lightning Assist peut tout faire comme Espanso ». Les déclencheurs à motifs regex et les correspondances adossées à des commandes shell sont de véritables points forts d'Espanso, sans équivalent GUI ici.

Étape par étape : importer vos fichiers de correspondance

Mis à jour le 7 septembre 2026 : Lightning Assist importe désormais directement les fichiers de correspondance Espanso, donc la recréation un par un décrite précédemment n’est plus nécessaire.

  1. Localisez vos correspondances existantes. Exécutez espanso path et ouvrez le dossier match indiqué (généralement ~/.config/espanso/match/). Chaque fichier .yml contenant une liste matches: peut être importé tel quel ; il n’est pas nécessaire de les fusionner au préalable.
  2. Installez le text expander GUI et ignorez tout fichier de configuration. Essayez Lightning Assist gratuitement pendant 14 jours — sans carte bancaire. L’application s’ouvre directement sur son panneau de snippets ; aucun fichier de configuration à créer.
  3. Importez chaque fichier de correspondance. Dans My Snippets, cliquez sur Importer et choisissez le fichier .yml. Chaque correspondance devient un snippet : trigger (ou la première entrée de triggers) devient le déclencheur, replace devient l’expansion, et label devient le nom du snippet si présent. Les symboles initiaux sont conservés, donc :br reste :br. L’import est disponible sur tous les plans. En version gratuite, chaque import ajoute jusqu’à 5 correspondances et la bibliothèque peut contenir 20 snippets ; la période d’essai de 14 jours augmente la limite à 20 par import, et le plan Pro supprime ces limites. Tout ce qui est exclu est listé, pas supprimé silencieusement.
  4. Vérifiez les variables. Les variables {{date}}, {{clipboard}} et {{form.field}} sont converties en placeholders correspondants, comme [#date#] et [#clipboard#]. Tout ce que l’importateur ne peut pas traduire — variables shell-command, scripts, déclencheurs regex — reste visible dans le texte d’expansion au lieu d’être supprimé, pour que vous puissiez le voir et le corriger. Si ces éléments sont essentiels à une correspondance, conservez-la dans Espanso.
  5. Configurez votre mode de déclenchement. L’expansion « au fur et à mesure de la frappe » (tapez le déclencheur, il s’expanse en ligne) est le mode par défaut et ne nécessite aucune configuration. Si vous préférez appuyer sur une touche après avoir tapé le déclencheur, configurez cela une fois dans Paramètres → Déclencheurs.
  6. Testez avant de supprimer quoi que ce soit. Essayez chaque snippet dans un document de test. Gardez votre configuration Espanso en place jusqu’à ce que vous ayez confirmé que la migration fonctionne comme prévu — il n’y a aucun mal à faire coexister les deux temporairement.

L’import lui-même prend quelques secondes ; le temps se consacre surtout à l’étape 4, la revue des correspondances utilisant des commandes shell ou regex. Pour une bibliothèque typique de correspondances en texte brut, la migration complète prend quelques minutes.

Ce que vous gagnez, et ce que vous perdez

Ce que vous gagnez : plus de fichiers de configuration, plus de boucle redémarrage-test, une bibliothèque de snippets consultable et organisée en dossiers, des commandes IA qui réécrivent ou traduisent le texte sélectionné via un raccourci, la reconnaissance vocale push-to-talk dans la même application, la synchronisation automatique dans le cloud entre appareils, et le partage de snippets en équipe si besoin. Tout cela fonctionne sur Windows, macOS et Linux avec un même compte.

Ce que vous perdez : Espanso est gratuit et open-source, pour toujours — Lightning Assist est aussi gratuit et illimité, avec jusqu’à 20 snippets, dossiers et une équipe inclus — mais une bibliothèque plus grande et plusieurs équipes coûtent 5,99 $/mois après un essai de 14 jours (le plan Pro inclut un crédit mensuel d’IA pour commandes et voix). Vous perdez aussi les déclencheurs basés sur regex et les correspondances shell-command, qui n’ont pas d’équivalent dans le modèle GUI. Si ces fonctionnalités sont la raison de votre usage d’Espanso, cette migration n’est pas pour vous — et c’est une raison légitime de rester.

Si vous souhaitez une interface graphique sans quitter complètement l’écosystème Espanso, des projets communautaires existent — espansoGUI (Rust/Iced, sur Flathub), EspansoEdit (freeware Windows) et l’IDE EspansoGUI. Ils valent le coup d’essayer, mais chacun est une couche distincte maintenue par des bénévoles au-dessus des mêmes fichiers YAML ; Espanso lui-même n’a toujours pas d’interface officielle au-delà de sa fenêtre de recherche (la dernière version stable du projet principal est la v2.4.1, 2 septembre 2026). Si vous voulez un outil où l’interface graphique est le produit, c’est ce que cette migration propose.

Questions fréquentes

Puis-je importer directement mes fichiers YAML Espanso ?

Oui. Dans My Snippets, cliquez sur Importer et sélectionnez un fichier de correspondance (.yml). Chaque paire trigger/replace devient un snippet, label devient le nom, et {{date}}, {{clipboard}} ainsi que les champs de formulaire deviennent des placeholders. Les variables shell-command et les déclencheurs regex n’ont pas d’équivalent et restent visibles dans le texte pour que vous puissiez les examiner.

Vais-je perdre mes déclencheurs regex ou mes correspondances shell-command ?

Oui. Ce sont des capacités spécifiques à Espanso basées sur son modèle YAML/scripting, et il n’y a pas d’équivalent GUI ici. Si les déclencheurs regex ou les correspondances shell-command sont essentiels à votre configuration, continuez à utiliser Espanso pour ceux-ci et envisagez un expander GUI uniquement pour vos snippets plus simples et statiques.

Puis-je conserver les mêmes textes déclencheurs, comme :br ou /addr ?

Oui. Le champ Déclencheur accepte tout texte que vous tapez, y compris un : ou / en début si c’est votre convention. Rien ne vous oblige à changer votre style d’abréviation lors de la migration.

Existe-t-il une interface graphique officielle Espanso à essayer avant de changer d’outil ?

Pas d’interface officielle. Des projets communautaires comme espansoGUI, EspansoEdit et l’IDE EspansoGUI ajoutent une couche graphique, mais ce sont des outils distincts maintenus par des bénévoles reposant sur les mêmes fichiers YAML — vous êtes toujours un pas en retrait de la configuration brute. Si vous voulez que l’interface graphique soit le produit complet et non un ajout, c’est la différence que cette migration propose.

Lectures associées

Sources

Articles similaires