Lapce mise sur Rust, Floem et un éditeur orienté distant
Éditeur de code ultra-rapide et puissant écrit en Rust. Lapce Éditeur de code ultra-rapide et puissant Lapce (IPA : /l ps/) est écrit en Rust pur, avec une interface utilisateur en Floem.
En bref
- De quoi s’agit-il ?
- Lapce est un éditeur de code Apache-2.0 avec LSP, édition modale, terminal intégré, plugins WASI et développement distant.
- À qui s’adresse-t-il ?
- Lapce s'adresse au développeur qui veut essayer un éditeur Rust avec édition Vim, LSP et environnements distants. Il est moins adapté si votre équipe dépend d'un écosystème d'extensions natif très large ou d'un support commercial, car le README ne le promet pas.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 2 jours.
- En quel langage est-il écrit ?
- Principalement Rust, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un éditeur dont la vitesse vient de la pile
Lapce se décrit comme un éditeur de code rapide et puissant écrit en Rust. Le dépôt précise que l'interface utilise Floem, que les calculs s'inspirent de Rope Science de Xi-Editor et que le rendu repose sur wgpu. Ces choix expliquent l'orientation technique annoncée, mais le README ne publie aucun benchmark, temps de démarrage ou consommation mémoire. Il faut donc distinguer l'intention d'architecture d'une mesure reproductible.
La branche par défaut est `master` et le projet est distribué sous Apache License 2. Cette licence autorise l'utilisation et la modification du code selon ses conditions, avec les notices et obligations prévues par Apache-2.0. Elle ne fournit pas de garantie sur les performances ni sur la stabilité des interfaces.
LSP et édition modale au premier plan
Le support intégré du Language Server Protocol fournit complétion, diagnostics et code actions. Lapce place aussi l'édition modale au premier rang, dans un mode inspiré de Vim qui peut être activé ou désactivé. Pour un développeur qui passe fréquemment du texte au terminal et aux actions de code, ces deux axes forment le cœur du produit documenté.
Le README ne liste pas les serveurs LSP inclus, la manière de gérer leurs versions ou les limites sur les gros dépôts. Un essai sérieux doit donc utiliser le langage réellement travaillé, vérifier qu'un serveur LSP reconnu démarre, puis observer les diagnostics et les actions dans un fichier comportant volontairement une erreur.
Le terminal reste dans l'espace de travail
Lapce intègre un terminal afin d'exécuter les commandes du workspace sans quitter l'éditeur. Ce choix réduit les changements de fenêtre, mais la source ne décrit ni le shell sélectionné, ni l'isolation, ni la gestion des variables d'environnement. Il ne faut pas transformer l'existence du terminal en promesse de compatibilité avec chaque outil de développement.
Les releases précompilées sont annoncées pour Windows, Linux et macOS. Le dépôt renvoie aussi vers `docs/installing-with-package-manager.md` et `docs/building-from-source.md`. Ces deux chemins sont plus utiles qu'une supposition sur les dépendances : ils permettent de vérifier la plateforme, la méthode d'installation et la version du binaire effectivement obtenue.
Développer sur une machine distante
Le développement distant intégré s'inspire de VSCode Remote Development. Lapce veut conserver une expérience locale tout en exploitant un système distant, et le projet associé Lapdev propose de gérer des environnements de développement distants. Le README établit cette orientation, mais ne détaille pas les transports, l'authentification, le montage des fichiers ou le comportement hors connexion.
Pour une équipe, ces inconnues sont importantes : un éditeur peut être agréable en local et moins prévisible sur un dépôt distant. Testez le même projet sur la cible prévue, lancez le terminal distant, modifiez un fichier et provoquez une complétion LSP. Notez les délais et les erreurs dans l'environnement Lapce choisi, au lieu d'extrapoler depuis la page d'accueil.
Plugins compilés vers WASI
Les plugins peuvent être écrits dans des langages capables de compiler vers WASI, notamment C, Rust et AssemblyScript. Le choix de WASI fournit un format commun annoncé par le projet, mais le README ne donne ni catalogue de plugins, ni version d'API, ni modèle détaillé de permissions. La surface réellement disponible pour un plugin doit être vérifiée dans la documentation et le code.
La contribution passe par `CONTRIBUTING.md`, un environnement Lapdev préconfiguré ou les canaux Discord, Reddit et Matrix. Le dépôt compte une communauté visible, mais les étoiles et les forks ne permettent pas de conclure sur la maturité d'une extension précise. Pour un usage d'équipe, vérifiez la licence du plugin autant que celle de Lapce et verrouillez la version de l'éditeur testée. Une vérification complémentaire doit conserver la release Lapce utilisée, le serveur LSP et la plateforme. Mesurez l ouverture d un dépôt réel, la complétion après une erreur syntaxique, l exécution d une commande dans le terminal intégré et une modification sur Lapdev. Notez les différences entre le binaire précompilé et une compilation depuis `docs/building-from-source.md`. Ainsi, l appréciation porte sur Floem, wgpu et le protocole LSP effectivement rencontrés.
Conclusion éditoriale
Lapce s'adresse au développeur qui veut essayer un éditeur Rust avec édition Vim, LSP et environnements distants. Il est moins adapté si votre équipe dépend d'un écosystème d'extensions natif très large ou d'un support commercial, car le README ne le promet pas. Installez une release depuis GitHub, ouvrez un projet avec un serveur LSP et comparez diagnostics, terminal et connexion distante avant de déplacer votre flux quotidien.
Notes de la communauté