30 avril 2026. Il est environ minuit. Je suis devant mon écran avec une idée simple : et si MOGWAI avait sa propre extension VS Code ? Vingt-quatre heures plus tard, elle était publiée sur le Marketplace. Voici l’histoire de comment ça s’est passé — et du rôle central qu’a joué Claude dans cette aventure.
L’idée de départ
MOGWAI existe depuis plus de dix ans. C’est un moteur de scripting RPN basé sur la pile, inspiré des calculatrices HP (HP 28S, HP 48), développé pour .NET et open-sourcé en février 2026 sous licence Apache 2.0. Il dispose déjà de son propre IDE — MOGWAI STUDIO — une application WinForms complète avec highlighting, autocomplétion, debug pas à pas, et bien plus.
Mais un IDE dédié, ça a ses limites. Beaucoup de développeurs ne veulent pas quitter VS Code. Ils ont leurs thèmes, leurs raccourcis, leurs habitudes. Et surtout, pour quelqu’un qui découvre MOGWAI pour la première fois, ouvrir un fichier .mog dans VS Code et voir du texte brut sans la moindre coloration, c’est une barrière immédiate.
L’idée était donc simple : créer une extension VS Code qui rende MOGWAI accessible directement depuis l’éditeur favori de la plupart des développeurs. Pas question de tout réimplémenter — juste ce qu’il faut pour coder confortablement.
Claude comme co-développeur
Je ne vais pas tourner autour du pot : cette extension a été développée en binôme avec Claude (Anthropic). Pas comme un simple outil de complétion de code, mais comme un véritable partenaire de développement.
La session a commencé par une conversation sur l’architecture. Quelles fonctionnalités voulais-je ? Comment le runtime MOGWAI communique-t-il ? Quels sont les formats de messages ? Claude a posé exactement les bonnes questions, dans le bon ordre, pour cadrer le projet avant d’écrire la première ligne de code.
Ce que j’ai particulièrement apprécié : Claude n’a jamais généré du code « en vrac ». Chaque fichier a été construit bloc par bloc, validé, puis assemblé. Quand quelque chose ne fonctionnait pas, on débogait ensemble — lui analysant les messages d’erreur, moi testant sur ma machine et lui remontant les résultats.
L’architecture en cinq fichiers
Une extension VS Code, c’est finalement assez simple dans sa structure. La nôtre tient en cinq fichiers principaux :
package.json — le manifeste. Il déclare le langage .mog, les commandes, les menus, les boutons de toolbar, les settings, et le panneau de la sidebar. C’est lui qui dit à VS Code « j’existe et voilà ce que je fais ».
language-configuration.json — la configuration du langage. Auto-closing des paires «», {}, [], (), ', ". Indentation automatique. Commentaires avec #. Rien de spectaculaire mais essentiel pour le confort de saisie.
mogwai.tmLanguage.json — la grammaire TextMate. C’est elle qui produit la coloration syntaxique des mots-clés statiques : structures de contrôle (if, while, foreach, forever…), opérateurs (->, =>, -->), sigils (&A, @A, !A), strings avec interpolation {! ... }, nombres, constantes.
mogwai.code-snippets — les snippets. Dix-huit structures prêtes à l’emploi : if/then/else, while/do, for, foreach, forever, switch, déclarations de fonctions avec ou sans paramètres typés, et plus encore.
extension.ts — le cœur de l’extension. 1186 lignes de TypeScript qui gèrent tout le reste : découverte UDP des runtimes, connexion TCP persistante, exécution de code, debug, panneau Runtime, autocomplétion dynamique.
Le protocole MOGWAI
Avant d’écrire une ligne de code réseau, il a fallu comprendre comment MOGWAI communique. Le runtime expose un protocole TCP/IP simple et élégant, basé sur des objets ServerMessage sérialisés en JSON :
{
"Source": "MOGWAI STUDIO",
"Function": "RUN",
"Parameters": ["mon code ici"]
}
Chaque message a une source, une fonction, et une liste de paramètres. C’est l’ordre des paramètres qui détermine leur signification. Simple, lisible, extensible.
La découverte des runtimes sur le réseau se fait via UDP : l’extension envoie un broadcast WHO IS HERE sur toutes les interfaces réseau, et les runtimes répondent avec I AM HERE en fournissant leurs informations de connexion et la liste complète de leurs primitives.
Une fois connecté, toutes les commandes transitent sur une connexion TCP persistante. Pas de nouvelle connexion à chaque échange — le socket reste ouvert de la connexion à la déconnexion explicite.
Le grand bug UDP
Parlons du moment le plus épique de cette session de développement : le bug UDP.
L’idée était simple — diffuser un message broadcast sur le réseau local pour découvrir les runtimes MOGWAI disponibles. MOGWAI STUDIO fait exactement ça, en C#, sans problème. Mais notre implémentation Node.js refusait obstinément de fonctionner.
On a d’abord cru à un problème de port — on bindait sur 255.255.255.255 au lieu de l’adresse de broadcast du sous-réseau. On a corrigé. Toujours rien.
Ensuite, le port 1968 était déjà occupé par le runtime lui-même. On a essayé reuseAddr: true. Windows a répondu EACCES. On a ajouté une règle de firewall. Toujours EACCES.
On a mis des logs partout. On a ouvert les DevTools de VS Code (Help → Toggle Developer Tools — peu de gens savent que c’est possible). Et là, on a vu nos messages partir, nos propres broadcasts nous revenir en écho… mais aucune réponse du runtime.
La clé était dans le code C# de MOGWAI STUDIO. Le runtime répond en unicast — directement à l’adresse source du paquet UDP reçu — et non en broadcast. Donc si on bind sur un port fixe, le runtime répond à ce port fixe, que le runtime lui-même occupe déjà. La solution : binder sur le port 0 (aléatoire), laisser le système choisir un port libre, et le runtime répond sur ce port. Simple, élégant, et ça a fonctionné immédiatement.
Trois heures de débogage pour un seul changement : remplacer socket.bind(udpPort, () => {… par socket.bind(0, () => {…
L’exécution et le debug
Une fois la connexion établie, l’exécution est remarquablement simple. On envoie le code via la commande RUN, et le runtime répond avec des messages structurés : PRG START au lancement, PRG STOP à la fin normale (avec la durée d’exécution), PRG ERROR en cas d’erreur.
Le message d’erreur est particulièrement riche : il contient le code d’erreur MOGWAI (MW.2, MW.21…), le message complet, et surtout les positions du premier et du dernier caractère de l’instruction en erreur dans le code source. L’extension se sert de ces positions pour surligner précisément la zone problématique en rouge dans l’éditeur et y positionner le curseur automatiquement.
Le mode debug va plus loin. La commande DEBUG au lieu de RUN active la prise en compte des points d’arrêt (debug.halt ou ¤). Quand le runtime se met en pause, il envoie PRG PAUSE suivi de PRG INFO avec la position de l’instruction courante — que l’extension surligne en bleu dans le code.
Depuis la toolbar de l’éditeur, des boutons contextuels apparaissent selon l’état : Pause pendant l’exécution debug, Step et Resume en pause. Tout disparaît quand le programme s’arrête.
Le panneau Runtime
L’une des fonctionnalités dont je suis le plus satisfait est le panneau Runtime, visible dans la sidebar de VS Code. Il affiche en temps réel l’état interne du moteur MOGWAI :
- Stack — le contenu de la pile RPN, avec l’index de chaque élément
- Variables locales — nom, type MOGWAI et valeur de chaque variable locale
- Variables globales — idem pour les variables globales
Ce panneau se rafraîchit automatiquement à chaque pause, chaque instruction TRACE, chaque fin d’exécution. Un bouton de rafraîchissement manuel est aussi disponible. Le tout en envoyant simplement trois commandes au runtime (?STACK, ?LVARS, ?VARS) et en parsant les réponses JSON.
Le highlighting dynamique
Une particularité de MOGWAI que l’extension gère avec élégance : les primitives disponibles varient selon le runtime. Chaque application qui héberge le moteur MOGWAI peut exposer ses propres primitives étendues, en plus des primitives standard.
Au moment de la connexion, le runtime transmet la liste complète de ses primitives avec leur groupe (GE pour General, MH pour Math, SK pour Stack, RT pour Runtime, ER pour Error, DG pour Debug). L’extension enregistre un SemanticTokensProvider qui colorie chaque primitive selon son groupe — exactement comme le ferait MOGWAI STUDIO avec son lexer Scintilla.
Ce highlighting se met à jour automatiquement quand on change de runtime.
L’autocomplétion
Dernier ajout avant la v1.0 : l’autocomplétion. Un CompletionItemProvider propose en cours de frappe :
- Les keywords statiques MOGWAI (
if,while,foreach,forever,class…) - Les primitives du runtime connecté, avec leur groupe en détail
Le filtre est basé sur le préfixe en cours de frappe. Les primitives MOGWAI ayant des noms parfois atypiques (->upper, +/-, ?d…), le pattern de correspondance est assez large pour les capturer correctement.
De zéro au Marketplace en 24 heures
Le 30 avril 2026 à minuit, on a commencé à parler architecture. Le 1er mai, l’extension était publiée sur le VS Code Marketplace sous l’identifiant mogwai.mogwai-language.
1762 lignes de code au total. Cinq fichiers. Une session de développement continue avec Claude. Zéro bibliothèque externe — uniquement Node.js natif et l’API VS Code
Pour installer l’extension, il suffit de chercher « MOGWAI » dans les extensions VS Code, ou d’aller directement sur : https://marketplace.visualstudio.com/items?itemName=mogwai.mogwai-language
Ce que j’ai appris
Développer une extension VS Code est beaucoup plus accessible qu’on ne le croit. L’API est bien documentée, TypeScript est un choix naturel, et le cycle compile/F5/test est rapide une fois mis en place.
Ce qui m’a le plus surpris : la qualité du résultat quand on travaille avec Claude de façon structurée. Pas « génère-moi une extension VS Code » — mais une conversation progressive, bloc par bloc, avec validation à chaque étape. Claude n’a jamais écrit de code sans avoir d’abord compris le contexte, le protocole, les contraintes.
Il y a eu des bugs. Il y en aura d’autres. Mais chaque bug a été l’occasion d’une vraie session de débogage collaborative — logs, hypothèses, tests, correction. Exactement comme avec un collègue humain.
MOGWAI Language Support continuera d’évoluer. Le debug pas à pas est déjà là. Les variables et la pile aussi. La prochaine version apportera peut-être les hover tooltips sur les primitives, ou une vue des tasks en cours d’exécution. Mais pour une v1.0 née en une nuit, je suis plutôt satisfait.
MOGWAI est disponible sur GitHub : https://github.com/Sydney680928/mogwai
L’extension VS Code est disponible sur le Marketplace : https://marketplace.visualstudio.com/items?itemName=mogwai.mogwai-language