evil helix
vil-helix-20240716
Une fourche douce d'hélice qui introduit des clés VIM et plus encore.
Important
Ce projet intègre souvent les derniers changements d'hélice, mais devrait être suffisamment stable pour l'utilisation quotidienne.
Téléchargez un package et extrayez-le dans /opt . De plus, il est recommandé de le symboliser dans /usr/local/bin :
cd /opt
sudo curl -Lo helix.tar.gz https://github.com/usagi-flow/evil-helix/releases/download/release- < VERSION > /helix- < ARCH > - < OS > .tar.gz
sudo tar -xf helix.tar.gz
cd /usr/local/bin
sudo ln -sv /opt/helix/hx .Si un package est disponible pour le gestionnaire de packages de votre système, c'est le moyen recommandé d'installer Evil Helix.
Ce sont les différences actuelles par rapport au projet en amont:
c , d , y , xiw , 0 , $color_modes est activé, colorez également le type de fichier dans l'état (5503542) De plus, Evil-Helix présente l'option editor.evil , ce qui est true par défaut. Il peut être défini sur False pour désactiver complètement le comportement de l'hélice maléfique sans avoir à utiliser une version différente:
[ editor ]
evil = true # Default; set this to `false` to disable evil-helix behavior Cette fourche cherche à implémenter les fonctionnalités dans le cadre de l'éditeur et à la rendre configurable. La fonctionnalité ajoutée comprend un look et une forme VIM, mais aussi d'autres fonctionnalités.
En revanche, le projet en amont, Helix, limite principalement sa portée à ses fonctionnalités de base actuelles et exploite une fonctionnalité supplémentaire vers le futur système de plugin basé sur le schéma.
Par rapport aux plugins, la mise en œuvre des fonctionnalités dans le cadre de l'éditeur améliore considérablement les performances et évite le risque de problèmes de compatibilité des plugins.
De plus, les valeurs par défaut raisonnables sont cruciales: l'éditeur doit offrir un large éventail d'outils pour votre travail, mais il doit faire ce que vous attendez qu'un éditeur fasse.
Le schéma / Lisp ne doit pas être forcé sur l'utilisateur. Il est sujet aux erreurs et plus difficile à lire par les humains, par rapport à Rust / Toml / Lua / ...
Si Helix en amont passe à une configuration basée sur un schéma, ce projet cherchera à conserver une alternative conviviale.
Ce projet est une "fourche douce", c'est-à-dire qu'elle reste compatible avec l'amont et réprimande régulièrement ses changements en plus de la branche maîtresse en amont. Les nouvelles fonctionnalités doivent être soigneusement isolées de la base de code en amont afin d'éviter les conflits.
La question de savoir si ce projet reste dans cet état dépendra de la quantité de philosophie de ce projet et du projet en amont, bien qu'une fourche dure soit considérée comme un dernier recours.
Compte tenu du type et de la fréquence des modifications de ce référentiel, il est logique de libérer souvent de petits changements, plutôt que de retenir les fonctionnalités dans de grandes versions. Les versions sont actuellement étiquetées à la demande.
Gardez à l'esprit que la branche main peut être rejetée sur la branche master en amont.
