Journal Tour d'horizon des éditeurs de texte pour le terminal

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
35
29
jan.
2015

Sommaire

Le nombre d'éditeurs de texte disponible sur nos systèmes d'exploitation est très important, même en se limitant à ceux s'exécutant dans un terminal.

La sélection suivante est donc forcement partielle. Dans la suite je parlerais des principaux éditeurs, de leurs clones, des anciens moins connu et enfin des plus récents.

La famille vi

La particularité de cette famille est d'être modale, les touches ont une action différente selon le mode dans lequel on est. De plus vi est dans la norme POSIX, donc tous les OS de type POSIX embarque un clone de vi.

Voir l'histoire de vi : wikipedia - Vi History

elvis

Elvis est un des premiers clone de vi (avec Stevie)

debian: tracker.debian.org/pkg/elvis

nvi

Nvi est une réécriture du vi des BSD 4.4 à partir du code d'Elvis.

debian: tracker.debian.org/pkg/nvi

vim

Vim est certainement le clone de vi le plus utilisé aujourd'hui. Il est disponible sur de nombreuses plateformes et une vie entière ne suffit pas a faire le tour de ses fonctions.

debian: tracker.debian.org/pkg/vim

neovim

Neovim est un fork de vim.

Voir la dépêche sur le sujet, neovim une refonte de vim pour le 21e siecle

debian:

kakoune

Éditeur qui s'inspire de vim mais a sa propre philosophie (voir le
répertoire doc/)

debian:

La famille emacs

M-x editeur

wikipedia - Liste des implémentations d'Emacs

emacs

On ne le présente plus, le plus difficile étant de trouver quelque chose qu'on ne peut pas faire dans emacs.

debian: tracker.debian.org/pkg/emacs24

note: se lance en ligne de commande avec l'option -nw pour
--no-window-system

uemacs

Version légère et portable d'emacs.

Linus Torvalds maintient une ancienne version de uemacs et l'a fait
depuis évoluer.

mg

Version très portable de uemacs nommé initialement Micro GNU/emacs.

debian: tracker.debian.org/pkg/mg

zile

zile est une implémentation d'emacs plus limité et plus légère.

debian: tracker.debian.org/pkg/zile

La famille à menu

Les éditeurs de cette famille ont comme point commun, d'être plus
abordable pour le novice en fournissant un menu permettant l'auto-découverte.

nano

Nano est la version GNU de Pico (Pine Composer), l'éditeur de texte du client mail Pine.

debian: tracker.debian.org/pkg/nano

Note: Pico est aussi disponible dans Debian,
packages.debian.org/jessie/alpine-pico

Jed

Jed associe les fonctionnalités d'un éditeur très extensible pour développeur à une interface facile basé sur un menu.

  • url: www.jedsoft.org/jed
  • filiation:

  • wikipedia: wikipedia - JED

  • code source: git://git.jedsoft.org/git/jed.git

  • début du développement: 2006 ?

  • langage : C + S-Lang

  • utf-8: ok

debian: tracker.debian.org/pkg/jed

ne

ne, le nice editor semble être un bon compromis entre richesse des
fonctions et simplicité. Cet éditeur possède un jeu de fonctions
(commandes) qui peuvent être lié a une séquence de touche ou à une
entrée de menu.

debian: tracker.debian.org/pkg/ne

mcedit

mc (mindnight commander) propose un éditeur très complet, mcedit.

debian: tracker.debian.org/pkg/mc

kaa

Encore un éditeur avec un menu, celui-ci extensible en Python.

debian:

Les autres

Des éditeurs qui ne rentrent pas dans les précédentes catégories ou qui peuvent les imiter toutes.

Joe

Un des plus ancien challenger.

debian: tracker.debian.org/pkg/joe

Fork www.mirbsd.org/jupp.htm

Diakonos

L'objectif principal de Diakonos est de proposer un éditeur en console avec les raccourcis clavier classique d'une application graphique tel un navigateur ou un traitement de texte.

debian: tracker.debian.org/pkg/diakonos

Yi

Yi est un éditeur de texte écrit et extensible en Haskell.

debian: tracker.debian.org/pkg/yi

Textadept

Textadept est un éditeur graphique qui propose aussi une interface
curse. Celui-ci est extensible en Lua. L'auteur utilisant le composant Scintilla pour la version graphique, celui-ci a développé une version pour curse scinterm

Spacemacs

Spacemacs n'est pas un éditeur, mais une (énorme) configuration pour
emacs. Leur baseline "The best editor is neither Emacs nor Vim, it's
Emacs and Vim!" et leur originalité un <leader> configuré sur espace qui ouvre un Menu permettant de découvrir les fonctions disponibles.

Conclusion ?

Pas de conclusion, si vous voulez en découvrir encore d'autre, voici deux listes :

Mais attention de ne pas vous perdre par ici texteditors.org !

  • # lequel

    Posté par  (site web personnel) . Évalué à 10.

    Intéressant, mais maintenant il manque ta réponse aux questions (qui sont bien différentes) :

    • lequel préfères-tu ?
    • lequel utilises-tu ?

    Et bien entendu en expliquant pourquoi. Comme ça les trolls commenceront à avoir quelque chose à se mettre sous la dents !

    Personnellement j’utilise vim parce que lorsque j’étais petit, l’éditeur que j’utilisais était un éditeur modal nommé ted sous DOS 3 (qui n’a probablement rien à voir avec tous les ted que vous avez déjà rencontré), il faut dire que même Word (pour DOS) était modal à l’époque. C’est avec cet éditeur modal nommé ted que j’ai écris mes premières lignes de C (K&R). Les commandes de ted et vim diffèrent, mais lorsque j’ai débuté sous GNU/Linux quelques années après, j’ai essayé emacs et je n’ai pas réussi à en sortir sans redémarrer l’ordinateur, alors que lorsque j’ai essayé vim, je n’ai rencontré aucune difficulté pour trouver comment m’en servir et en sortir, c’était juste évident et tout ce qu’il y a de plus naturel.

    Quand j’étais petit j’ai appris à me servir d’un ordinateur avec sa console, c’est à dire en discutant avec mon ordinateur, et j’ai aussi appris à me servir d’un éditeur modal, c’est à dire en discutant avec mon éditeur. On dit que l’histoire commence avec l’écriture, mais la civilisation commence avec le langage. ;-)

    Depuis, je ne sais toujours pas comment on quitte emacs, car je n’ai pas réessayé, vim me convient très bien, comme au premier jour.

    J’utilise vim parce que c’est l’éditeur qui m’a paru le plus naturel lorsque j’ai débuté sous GNU/Linux, et je préfère vim parce que… j’ai passé trop de temps avec pour m’en séparer. :-)

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: lequel

      Posté par  (site web personnel) . Évalué à 10.

      Je pensais avoir laissé assez d'indices et de trolls !

      Si il faut préciser j'utilise vim, mais je dois avouer que j'ai mis assez longtemps à m'y mettre ; c'est cette réponse StackOverflow qui m'a fait débloquer un level : Your problem with Vim is that you don't grok vi (D'ailleurs j'ai commencé une traduction française)

      Dans un autre registre j'ai longtemps utilisé Scite et l'utilise parfois encore.

      • [^] # Re: lequel

        Posté par  . Évalué à 4.

        Le commentaire de Stack Overflow que tu cites est absolument super. J'utilise vim depuis 4 ans, et j'ai (re)découvert à quel point vi est encore plus puissant que ce que je ne croyais. Sincèrement, ça vaut le coup de le lire, merci.

        D'ailleurs ce commentaire s'adresse à la fois au vi-iens, et non vi-iens, car il explique la puissance de ce logiciel sans nécessiter le moindre pré-requis.

        --> Une fois de plus, aller lire ce lien, ça serait vraiment dommage de passer à côté !

        bépo powered

      • [^] # Re: lequel

        Posté par  . Évalué à 4.

        Je vais lire ce message, mais, franchement, la personne qui à ouvert le thread n'a pas été bien loin avant de demander…

        Perso, quand j'ai vraiment voulu tester, j'ai commencé par la simple commande "vimtutor", découverte en faisant vi sur mon bash. Hors, la leçon 5.3 indique:

        NOTE : L'appui de v démarre la sélection Visuelle. Vous pouvez déplacer le
        curseur pour agrandir ou rétrécir la sélection. Puis vous pouvez
        utiliser un opérateur pour faire quelque chose sur le texte. Par
        exemple, d efface le texte.

        Du coup, ce passage:

        Copy/Cut & paste. I do it all the time. With all the contemporary editors you press Shift with the
        left hand, and you move the cursor with your right hand to select text. Then Ctrl+
        C copies, you
        move the cursor and Ctrl+
        V pastes.

        With Vim it's horrible:
        yy to copy one line (you almost never want the whole line!)
        [number xx]yy to copy xx lines into the buffer. But you never know exactly if you've selected what you wanted. I often have to do [number xx]dd then u to undo!

        Révèle surtout le manque de RTFM de son auteur, non? Parfois, c'est clair, les manpages n'aident pas aisément un vrai débutant (souvent, en fait), et il est difficile de trouver de bons tutos. Sauf que quand même, vim intègre le tuto dans le paquet… que faut-il de plus?

        Pour l'avoir fait, lire le vimtutor (traduit selon la locale du système en plus!) permets de savoir faire toutes les opérations de base et semi-évoluées (se déplacer à un endroit précis du fichier n'est pas basique, mais ce n'est pas non plus une utilisation avancée amha) que l'on fait avec les éditeurs classiques, en se passant de la souris. Donc, gain de temps, à condition de faire l'effort d'apprendre.

        Par contre, j'admets, sur le coup du copier/coller ou le coup de la recherche, vim est pénible: dès qu'on supprime un truc ça remplace la copie précédente si on n'explicite pas un registre (2 frappes clavier de plus, quand même, perso je trouve ça chiant), et la recherche qui ne se fait que par des regex n'aide pas non plus. Mais je suis persuadé que ces inconvénients sont surtout issus de mon manque de connaissance de vim.
        Vais sûrement aussi aller tester kakoune, pour le coup. M'à l'air prometteur, même s'il n'est pas standard POSIX (chose que j'ai apprise via ce journal, d'ailleurs. Génial, ça veut dire que je peux confortablement éditer du texte sur n'importe quel système POSIX, plutôt une excellente nouvelle!).

        • [^] # Re: lequel

          Posté par  . Évalué à 3.

          Ah, et, maintenant que j'y pense, au sujet des regex…

          et la recherche qui ne se fait que par des regex n'aide pas non plus

          C'est vrai, mais il est possible de ne pas utiliser le '/' comme séparateur (je m'en sers surtout pour les substitutions, genre :%s!hello/world!world/hello!g qui évite de devoir échapper les /, super utile quand on programme). Je crois qu'on peut utiliser tous les signes de ponctuation, à confirmer.

          Personnellement j'utilise beaucoup le ! pour séparer, j'utilise moins ce caractère que les / (oui, je fais moins souvent des comparaisons de différence que je n'utilise des /, même en C++, et surtout je ne fait quasi jamais de regex les impliquant) et ce caractère à le très gros avantage d'être très simple d'accès: petit doigt de la main droite en azerty, c'est plus rapide que / qui nécessite un shift. Je pourrais utiliser < aussi, mais ce caractère me sert souvent. Fonction des usages donc.

          Voila, donc du coup à part pour les caractères spécifiques aux regex, pas besoin d'échapper le reste. Me semble même avoir lu qu'on pouvait utiliser des chaînes de caractères, mais je ne mettrais pas ma main à couper, je n'ai jamais essayé.

        • [^] # Re: lequel

          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 30 janvier 2015 à 17:28.

          Vais sûrement aussi aller tester kakoune, pour le coup. M'à l'air prometteur

          Je garde un oeil sur lui aussi, de toute la famille vi c'est le seul qui va au delà du clone et repense l'interaction avec le texte.

          • [^] # Re: lequel

            Posté par  . Évalué à 2.

            Au fait, quelqu'un à réussi à le compiler?

            Perso impossible, peut-être à cause du fait d'avoir boost en 1.49 (l'auteur indique 1.50 minimum) mais l'erreur que je garde ne semble pas liée à boost:

            /kakoune/src$ make
clang++ -std=c++11 -std=gnu++11 -g -Wall -Wno-reorder -Wno-sign-compare -pedantic -DKAK_DEBUG -MD -MP -MF .main.d -c -o .main.o main.cc
main.cc:440:21: error: call to constructor of 'Kakoune::SelectionList' is ambiguous
                    { buffer, {{0,0}, buffer.back_coord()} },
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./selection.hh:75:5: note: candidate constructor
    SelectionList(Buffer& buffer, Selection s);
    ^
./selection.hh:77:5: note: candidate constructor
    SelectionList(Buffer& buffer, Vector<Selection> s);
    ^
./input_handler.hh:41:32: note: passing argument to parameter 'selections' here
    InputHandler(SelectionList selections,
                               ^
1 error generated.
make: *** [.main.o] Erreur 1

            J'avais aussi une tonne d'erreurs sur size_t non défini, que j'ai résolues en incluant stddef.h dans hash.hh. Si je pouvais le faire compiler sous Debian stable (bon, à l'exception près que j'ai inclus clang 3.5 du repo de officiel de clang, au lieu de celui de debian qui dépend toujours d'une libc++ qui date d'old stable… sigh)

            • [^] # Re: lequel

              Posté par  (site web personnel) . Évalué à 1.

              Au fait, quelqu'un à réussi à le compiler?

              Sous Jessy sans problèmes, j'ai pas essayé avec Wheezy.

              • [^] # Re: lequel

                Posté par  . Évalué à 3.

                Peut-être à cause de la libstdc++… il semble que sous jessie c'est la 4.8 minimum alors que sur wheezy on est au max en 4.7. Faudrait que je voie si un paquet plus récent existe, ou pour juste back-porter le code de kakoune (ça ne devrait pas être trop compliqué après tout).

                • [^] # Re: lequel

                  Posté par  (site web personnel) . Évalué à 2.

                  Si tu te penche sérieusement sur kakoune, n'oublie pas de faire un retour par ici ;-)

                  • [^] # Re: lequel

                    Posté par  . Évalué à 2.

                    Dès que compilé ;)

                    J'ai toujours râlé après vim pour diverses raisons, et sur le papier kakoune en résouts au moins une: éditer un fichier avec plusieurs instance de l'éditeur.
                    Donc il est clair que je vais tester, seulement je ne me sens pas chaud pour passer à Jessie pour un éditeur de texte, donc j'aimerai bien le compiler pour Wheezy…

                    • [^] # Re: lequel

                      Posté par  (site web personnel) . Évalué à 3.

                      En tous cas, il faut une version de gcc assez récente. Je l'ai compilé sur OpenBSD et j'ai du installé le gcc des ports (en même temps, sur OpenBSD de base ils n'actualisent plus les versions gcc depuis longtemps). J'ai pas réussi avec Clang, par contre, mais vu que j'y connais très peu, c'était peut-être juste qu'il manquait le bon flag. Sinon, j'ai du faire aussi un hack tout moche dans un des fichiers source (mettre un chemin en dur), mais ça devrait pas être nécessaire sous Linux.

                      Mon impression est que c'est original, le langage est vraiment orthogonal, et le fait de pouvoir splitter une sélection avec une expression régulières en plein de petites sélections est pas mal du tout. Après, en pratique, je ne trouve pas que ça change tant que ça, c'est juste un peu plus intéractif (donc sans doute plus facile à apprendre, parce qu'on voit la sélection à laquelle on applique la commande). L'aide intéractive pour les commandes est pas mal au début… mais je me demande si à la longue c'est pas lourd (c'est pas très discret), et j'ai pas vu comment la désactiver. Un vrai inconvénient, c'est qu'il manque encore beaucoup de choses pour que ce soit utilisable pour tous les besoins : les expressions régulières, par exemple, sont un peu basiques (. ne matche pas un caractère utf8, mais un byte, ils ont déjà un tiquet sur ça : j'espère qu'ils iront vers du pcre ou quelque chose de mieux), il manque des petites commandes typiques que j'utilise en vim couramment (aller jusqu'à tel ou tel caractère et des choses comme ça), et pour les plugins c'est un peu dans les débuts. Les performances sont correctes, il me semble (mais j'ai pas fait de vrai test pour comparer avec vim). J'ai pas remarqué de bugs flagrants, à part une assertion ou quelque chose comme ça qui a raté à un moment avec un petit panneau d'erreur, mais j'ai pas réussi à reproduire ensuite (j'ai pas trop fait attention sur le moment à ce que je faisais, vu que je testais un peu au pif).

                      Il y a un truc que j'aime pas trop, c'est que certains raccourcis passent par alt (ce qui a le mauvais goût d'entrer en conflit avec mon gestionnaire de fenêtres), mais bon, c'est possible de remapper, donc pas vraiment un problème, a priori.

                      J'ai pas non plus beaucoup testé, il manque trop de plugins dont j'ai besoin, mais le concept est décidément original (même si je ne suis pas sûr personnellement de préférer autant d'intéractivité par rapport au mode ex de vim).

                      • [^] # Re: lequel

                        Posté par  . Évalué à 2.

                        Par curiosité, quels plugins vim te manquent ?

                        Le coup du . qui matche que les bytes, c'est effectivement un problème lié à boost::regex, à fixer dans le futur mais je ne suis pas sûr d'avec quoi. PCRE est assez tentant car plutôt répandu.

                        aller jusqu'au prochain char existe, et c'est comme vim (f et t). À moins que tu fasse reference à une autre fonctionalité ?

                        • [^] # Re: lequel

                          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 02 février 2015 à 21:17.

                          Par curiosité, quels plugins vim te manquent ?

                          Eh bien, je n'ai pas vu de choses comme ultisnips (celui-là je l'aime bien), ou syntastic (mais ça je peux m'en passer la plupart du temps, à part pour faire du OCaml, où j'aime bien). C'est peut-être facile à faire, j'ai pas trop étudié la question. Après, dans les trucs plus particuliers, j'ai pas trouvé par exemple de coloration pour Perl (mais j'avoue que ça ne doit pas être très amusant à faire).

                          aller jusqu'au prochain char existe, et c'est comme vim (f et t). À moins que tu fasse reference à une autre fonctionalité ?

                          Oui, quand j'ai écrit je ne me souvenais plus trop, mais ce qui marche pas (mais j'ai peut-être pas trouvé, et il y a un équivalent), c'est "F" et "T", pour faire dans l'autre sens (j'ai l'impression que ça fait la même chose que sans majuscules), et ";" pour répéter au cas où on cherche la deuxième occurrence.

                          En tous cas, malgré ces petits détails, je trouve ton éditeur de texte très original, et plus accessible que vim grâce à son côté intéractif, et les commandes "g*" sont plus faciles à utiliser (avec vim j'ai tendance à avoir des trous de mémoires pour faire certaines de ces choses), même si je me plante et j'utilise le dollar quand il faut pas, par habitude.

                          Bonne chance pour la suite !

                          • [^] # Re: lequel

                            Posté par  . Évalué à 1.

                            Oui, quand j'ai écrit je ne me souvenais plus trop, mais ce qui marche pas (mais j'ai peut-être pas trouvé, et il y a un équivalent), c'est "F" et "T", pour faire dans l'autre sens (j'ai l'impression que ça fait la même chose que sans majuscules), et ";" pour répéter au cas où on cherche la deuxième occurrence.

                            Ahh, alors pour inverser le sens, c'est alt-f et alt-t. F et T vont étendre la sélection (d'une manière générale, les commande majuscules étendent la sélection plutôt que la remplacer, W par exemple étend la sélection jusqu'au début du prochain mot)

                            Il n'y a, par contre, aucune commande équivalent à ;.

                            Au passage, l'utilisation de alt (plutôt que ctrl) est due au fait que ctrl ne supporte ni les majuscules, ni toutes les touches (dans un terminal j'entends).

                            • [^] # Re: lequel

                              Posté par  (site web personnel) . Évalué à 2.

                              Ahh, alors pour inverser le sens, c'est alt-f et alt-t. F et T vont étendre la sélection (d'une manière générale, les commande majuscules étendent la sélection plutôt que la remplacer, W par exemple étend la sélection jusqu'au début du prochain mot)

                              Ah, cool.

                              Au passage, l'utilisation de alt (plutôt que ctrl) est due au fait que ctrl ne supporte ni les majuscules, ni toutes les touches (dans un terminal j'entends).

                              En plus, ctrl est moins accessible. J'aurai plutôt pensé à une combinaison de deux touches normales (comme pour les g*).

                              Puisque j'en suis à décrire mon expérience, un autre détail que j'ai remarqué : quand j'écris du texte, puis fais <esc>, il y a un petit timeout (normal), mais si j'écris rapidement d'autres lettres après <esc> sans attendre un minimum, celles-ci sont interprétées dans le mode insertion et insérées dans le texte, et pas interprétées dans le mode normal après le <esc> (c'est pas comme ça dans vim).

                              • [^] # Re: lequel

                                Posté par  . Évalué à 1.

                                Puisque j'en suis à décrire mon expérience, un autre détail que j'ai remarqué : quand j'écris du texte, puis fais , il y a un petit timeout (normal), mais si j'écris rapidement d'autres lettres après sans attendre un minimum, celles-ci sont interprétées dans le mode insertion et insérées dans le texte, et pas interprétées dans le mode normal après le (c'est pas comme ça dans vim).

                                Alors, Kakoune utilise un délai pour séparer esc de alt-quelquechose, ce delai est de 25ms, par contre si tu l’utilises dans tmux, tmux aussi a un délai, et il est plutôt haut par défaut (500ms), il faut mettre set -sg escape-time 25 dans son .tmux.rc pour avoir un délai total de 50ms.

                                • [^] # Re: lequel

                                  Posté par  (site web personnel) . Évalué à 2.

                                  Ah, effectivement, merci du conseil ! Sur vim je n'y avais pas fait attention, parce que, même si l'affichage était retardé, c'était comme si c'était juste l'affichage.

                          • [^] # Re: lequel

                            Posté par  . Évalué à 2.

                            Eh bien, je n'ai pas vu de choses comme ultisnips (celui-là je l'aime bien), ou syntastic (mais ça je peux m'en passer la plupart du temps, à part pour faire du OCaml, où j'aime bien). C'est peut-être facile à faire, j'ai pas trop étudié la question. Après, dans les trucs plus particuliers, j'ai pas trouvé par exemple de coloration pour Perl (mais j'avoue que ça ne doit pas être très amusant à faire).

                            Rien pour le moment de comparable à utilsnips, par contre pour Syntastic, clang.kak fourni pour C/C++ non seulement la completion automatique, mais aussi l'affichage des erreurs/warning en direct (marqueur rouge/jaune a gauche de la ligne, et affichage de l'erreur sous le curseur quand celui ci est sur une ligne marqué)

                            img

                            Par contre il faut l'activer avec un hook dans son kakrc:

                            hook global WinSetOption filetype=cpp %[ clang-enable-autocomplete; clang-enable-diagnostics ]

                            Pour perl, oui, il n'y a pas encore d'highlighting fait.

                            • [^] # Re: lequel

                              Posté par  (site web personnel) . Évalué à 2.

                              Pas mal le clang.kak !

                              Je sens que je vais continuer à utiliser kakoune, au moins de temps en temps, puis je m'y mettrai peut-être vraiment à un moment si j'ai un peu de temps. D'ailleurs, les plugins ont l'air plus faciles à faire qu'avec vimscript, et j'aime bien la philosophie assez minimaliste de kak, et le fait que kakoune n'est pas un monstre de quelques centaines de milliers de lignes, contrairement à vim.

                        • [^] # Re: lequel

                          Posté par  . Évalué à 2.

                          Au sujet des regex, peut-être que switcher sur la STL (après tout, tu indiques déjà qu'il faut le support de C++11) règlerai ce souci de byte vs char? En général, il me semble que les nouvelles libs de C++11 sont très proches de boost, voire je crois avoir vu des libs de boost évoluer vers la STL après adoption d'une version modifiée de la dite lib de boost.

                          Et pour ce qui est du type de regex utilisé, je suppose que ce ne serait pas difficile de laisser le choix via une option de configuration? Dans le cas de la STL, il s'agit d'une simple constante à changer. J'imagine que c'est la même chose pour boost.

                          • [^] # Re: lequel

                            Posté par  . Évalué à 1.

                            C’était le plan, sachant que les regex n'ont été implémenté qu'à partir de GCC 4.9 (donc pas encore hyper courant). En pratique il y a déja un #define dans le code qui permettrait de passer aux regex STL, mais certaines features utilisé très courrament dans les scripts .kak ne sont malheureusement pas supporté par les regex standard:

                            \h (horizontal whitespace) pas très grave, remplaçable par [ \t]
                            \K (set match start position) plus embêtant, et très utilisé

                            Du coup, pour \K, soit je trouve une solution pour le remplacer (une feature C++ pour remplacer une feature regex), soit je migre vers un moteur de regex différent (comme PCRE).

                            Pour le moment, comme de toute manière il faut GCC 4.9, je garde le status quo avec boost. Mais ça fait parti des choses à faire.

                            • [^] # Re: lequel

                              Posté par  . Évalué à 2.

                              C'est quel flag, qui permets d'utiliser std::regex?

                              Et au sujet du support, la page officielle indique un support total des regex depuis 4.7, qui est inclue par défaut dans Debian Wheezy.

                              Pour les deux autres problèmes par contre, je ne sais pas.

                              PS: j'aime beaucoup ça: It is a code edtior, and not a window manager.. Bon sang, je l'ai pensé tellement souvent, merci!

                              • [^] # Re: lequel

                                Posté par  . Évalué à 1. Dernière modification le 03 février 2015 à 12:46.

                                C'est quel flag, qui permets d'utiliser std::regex?

                                il faut definir KAK_USE_STDREGEX (soit via CXXFLAGS, soit directement dans regex.hh), mais cela va casser la grande majorité des scripts d'highlighting.

                                Et au sujet du support, la page officielle indique un support total des regex depuis 4.7, qui est inclue par défaut dans Debian Wheezy.

                                Sur la page, je vois tout les features regex en non supporté. Non pardon c'est pour la TR1. En tout cas je suis sûr que c'est uniquement depuis GCC 4.9 que std::regex est disponible, si ca avait été dispo plus tôt, j'aurais pas eu besoin de boost::regex du tout.

                                • [^] # Re: lequel

                                  Posté par  . Évalué à 2.

                                  Effectivement, je n'ai pas scrollé assez on dirait. Me suis fait avoir: j'ai vu que les classes de regex étaient ok, mais pas regardé les fonctionnalités… en gros ça marche mais ça fait rien sigh

                                  • [^] # Re: lequel

                                    Posté par  . Évalué à 1.

                                    Ah oui ça me reviens, effectivement ça compile, mais rien n'est implémenté. C'est un peu le pire des cas.

                      • [^] # Re: lequel

                        Posté par  . Évalué à 2.

                        J'ai pas réussi avec Clang, par contre

                        Surprenant, parce que l'auteur indique que clang est supporté (mais peut-être ta version est-elle trop vieille?). Quels étaient tes messages d'erreur?

                        Sinon, j'ai du faire aussi un hack tout moche dans un des fichiers source (mettre un chemin en dur),

                        Quel fichier, pour quel include? Il devrait être possible de faire ça plus proprement et de soumettre un patch.

                        (. ne matche pas un caractère utf8, mais un byte, ils ont déjà un tiquet sur ça : j'espère qu'ils iront vers du pcre ou quelque chose de mieux)

                        Vu que c'est l'usage de C++11 qui est fait, et que les regex sont intégrées dans le langage depuis… C++11, je pense qu'ils vont utiliser la STL, du coup il devrait y avoir le choix.
                        Ce que tu décris est plutôt une problématique d'encodage amha.

                        • [^] # Re: lequel

                          Posté par  (site web personnel) . Évalué à 2.

                          Surprenant, parce que l'auteur indique que clang est supporté (mais peut-être ta version est-elle trop vieille?). Quels étaient tes messages d'erreur?

                          C'est juste qu'il ne me trouve pas certains includes comme <cstdint> (clang 3.5), je ne pense pas que ce soit un bug. J'ai jamais fait de C++ sur OpenBSD, mais je suppose que pour quelqu'un qui sait, ça doit être juste lancer make avec un flag en plus.

                          Quel fichier, pour quel include? Il devrait être possible de faire ça plus proprement et de soumettre un patch.

                          Non, ça c'est dans file.cc, où une façon non portable pour récupérer le chemin de l'exécutable est utilisée, mais c'est pas un bug : c'était prévu pour lancer une erreur si l'OS n'est pas Linux, Cygwin ou OSX. Comme j'avais pas envie de réfléchir à comment on peut faire sur OpenBSD ça facilement, je l'ai mis en dur. A priori j'aurai pensé à argv pour ce genre de choses.

                          Ce que tu décris est plutôt une problématique d'encodage amha.

                          Pas vraiment, qu'un éditeur (ou langage) supporte utf8 pour beaucoup d'opérations ne veut pas dire que ça va être aussi le cas de ses expressions régulières, elles travaillent probablement au niveau des "bytes" sans se soucier d'encodage.

                          • [^] # Re: lequel

                            Posté par  (site web personnel) . Évalué à 2.

                            C'est juste qu'il ne me trouve pas certains includes comme (clang 3.5), je ne pense pas que ce soit un bug. J'ai jamais fait de C++ sur OpenBSD, mais je suppose que pour quelqu'un qui sait, ça doit être juste lancer make avec un flag en plus.

                            Bon, j'ai compris pourquoi, finalement : la version de clang d'openbsd vient sans la libc++, tout simplement !

            • [^] # Re: lequel

              Posté par  . Évalué à 1.

              Bonsoir,

              Je suis l'auteur de Kakoune, je viens de pusher sur github une serie de commits, dont le dernier devrait fixer cette erreur de compilation.

              N'hesitez pas à me demander si vous avez des questions, j'arrive à un stade avec Kakoune ou je souhaite le faire decouvrir à plus de monde et obtenir plus de retours, donc je suis ce thread avec interêt.

              • [^] # Re: lequel

                Posté par  (site web personnel) . Évalué à 4.

                Salut!

                Merci d'être passé sur ce thread.

                Pour faire découvrir Kakoune à plus de monde, une dépêche sur linuxfr semble une bonne idée ;-)

                Avec plus de 3 ans de développement et plus de 12k ligne de code c++ tu dois avoir des choses à raconter ! Surtout sur tes choix techniques. Tu les défends d'ailleurs sur un thread de la ML suckless.org : Re: [dev] Plain text editor that sucks less - an alternative to VIM?

                Pour la bibliothèque d'expression régulière il y a aussi re2 qui revient souvent.

                Bonne continuation pour le développement de Kakoune.

              • [^] # Re: lequel

                Posté par  . Évalué à 2.

                Avec une compilation via clang 3.5:

                selection.cc:53:11: warning: unused function 'update_erase' [-Wunused-function]

                Aussi, dans le Makefile, remplacer std=gnu++11 par std=c++11 compile, ici. L'avantage c'est que c'est plus standard, donc ça t'éviteras de potentielles emmerdes dues aux extensions de GNU. Pourrait être utile, vu que clang me semble de plus en plus populaire (sur les unix libres, mais personnellement c'est aussi mon compilo de prédilection, pour sa vitesse et ses erreurs qui ressemblent moins à des incantations vaudou).

                J'ai réussi à compiler, vais tester ça tranquillement.

                • [^] # Re: lequel

                  Posté par  . Évalué à 1.

                  Avec une compilation via clang 3.5:

                  selection.cc:53:11: warning: unused function 'update_erase' [-Wunused-function]

                  Oui, je garde ce code pour référence, faudrait peut être que je le commente pour virer ce warning.

                  Aussi, dans le Makefile, remplacer std=gnu++11 par std=c++11 compile, ici.

                  En fait, j'utilise std=gnu++11 parce que certaines versions de clang rejettent certaines constructions dans libstdc++ (la lib standard c++ fourni par GCC) avec std=c++11. Mais c'est bien possible que ça ne soit plus nécessaire avec des clang récent.

                  J'ai réussi à compiler, vais tester ça tranquillement.

                  J'attends tes retours !

              • [^] # Re: lequel

                Posté par  . Évalué à 1.

                Bonjour,
                plutôt que de polluer ton bugtracker avec des question de débutant, je me permet de t'écrire ici quelque remarques.

                Je suis en bépo (pas en azerty), et j'ai voulu faire l'inversion « j <-> t » et « s <-> k » pour que les touches haut et bas soit sous ma position de repos. « :map global normal t j » marche très bien, (de même pour les majuscules), par contre je n'ai trouvé le moyen de faire l'inversion « gj <-> gt » et « gs <-> gk ».
                J'ai trouvé dommage que sur les commandes longues (genre « :set »), l'aide ne s'actualise pas au fur et à mesure pour donner une description plus détaillé des mots-clés (je n'ai par exemple pas compris à quoi correspondent les modes « menu, prompt et user »).

                D'ailleurs je trouve le trombone génial pour comprendre rapidement le logiciel, mais il manque une command « :help » pour trouver la commande à utiliser (exemple « :help vertical-selection », « :help syntax-color » ou encore « :help <alt-r> ».

                Encore une question : comment fait-on pour récupérer la sélection précédente ? (l'équivalent de « gv » et « 1v » sous vim) ?

                bépo powered

                • [^] # Re: lequel

                  Posté par  . Évalué à 1.

                  Alors pour gj <-> gt, c'est un problème de documentation. map supporte aussi le mode 'goto' qui permet de mapper les touches après 'g' et 'view' qui permet de mapper les touches après 'v'. Dans ton cas, tu veux faire ':map global goto j t'

                  Pour l'aide sur les options dans :set, oui, d'autant plus que les options ont déja de la doc associé, il faut juste refactorer le systeme d'aide pour que les commandes puissent le mettre à jour.

                  Et pareil pour :help, c'est à faire.

                  Pour la sélection précédente, on peut retourner vers le 'saut' précédent avec c-o (comme dans Vim), suivant avec c-i, et pusher la sélection courante en tant que saut avec c-s. Tout le changements de sélections ne pushent pas forcement un saut (en général, les recherche regex et le commandes g-quelquechose le font).

                  Et pour finir, l'option 'autoinfo' contrôle l'affichage du trombone, 0 desactive, 1 est le comportement par défaut, 2 l'active aussi sur les commandes normales, expliquant ce que la touche viens de faire.

                  • [^] # Re: lequel

                    Posté par  . Évalué à 1. Dernière modification le 05 février 2015 à 13:43.

                    Super, merci.

                    Je pense que dans un premier temps la commande :help pourrait tout simplement afficher le readme de github est assez complet (histoire d'avoir rapidement qqch).

                    Pour la sélection verticale (ctrl+v de vim), est ce qu'il y a l'équivalent sous kakoune ?

                    bépo powered

                    • [^] # Re: lequel

                      Posté par  . Évalué à 1.

                      Pour la sélection verticale le pattern classique serait:

                      sélectionne les lignes qui t’intéressent ('xXXXX' par exemple, ou bien 'alt-i p' pour un paragraphe). pour splitter sur les fin de lignes. Te voila avec une sélection par ligne. Tu peu maintenant utiliser les mouvement habituels pour effectuer ton changement. te permet de revenir a une seul sélection.

                      • [^] # Re: lequel

                        Posté par  . Évalué à 1.

                        J'ai pas compris. Supposons que j'ai le texte suivant (avec le curseur sous le « v » :
                         
                         

                            v
aaaabbbb
aaaacc
aaaa
aa
aaaadd

                        Je souhaites obtenir le texte suivant

                        aaaaXXbbbb
aaaaXXcc
aaaaXX
aa
aaaaXXdd

                        Sous vim, je ferais « <C-v>5j2IX<Esc> » (NB : le I est un i majuscule)

                        Comment fait-on sous kakoune ?

                        De même, en partant de

                            v
aaaabbbbxxxx
aaaacc  xxxx

dd
dd

                        Je souhaites obtenir

                            v
aaaabbbbxxxx
aaaacc  xxxx

ddbbbb
ddcc

                        Sous vim, je ferais « <C-V>3ljy3jp » (NB : le l est un L minuscule). Comment fait-on avec kakoune ?

                        J'ai l'impression que sur les opérations de base, kakoune est plus efficace que vim, mais les selections verticales sont quelquechose qui me manque.

                        PS - J'ai tellement l'impression de me moucher sur mon clavier quand je racontes des commandes vim :)

                        bépo powered

                        • [^] # Re: lequel

                          Posté par  . Évalué à 1. 

                              v
aaaabbbb
aaaacc
aaaa
aa
aaaadd

                          Je souhaites obtenir le texte suivant

                          aaaaXXbbbb
aaaaXXcc
aaaaXX
aa
aaaaXXdd

                          5Xs^.{4}<ret>aXX<esc>

                          Si il n'y avait pas la ligne ^aa$, on aurait aussi pu faire:

                          4X<a-s><a-f>a;aXX<esc>

                          La ou le mode colonne de vim est meilleur, c'est qu'il te permet de descendre au
                          milieu des lignes, pour le moment Kakoune ne fourni riens de tel, il faut sélectionner
                          les lignes puis splitter pour arriver ou tu le veux. En pratique, pour éditer du code,
                          ça marche très bien.

                              v
aaaabbbbxxxx
aaaacc  xxxx

ddbbbb
ddcc

                          Je souhaites obtenir

                              v
aaaabbbbxxxx
aaaacc  xxxx

ddbbbb
ddcc

                          xX<a-s><a-f>al3Ly3jp

                          Encore une fois, la vim ici marche mieux car j en mode block va directement a la meme colonne.

                          Si le mode colonne manque trop, on pourrait ajouter une commande kakoune qui duplique la
                          sélection principale a la ligne suivante (ou plus si préfixe d'un nombre).

                          avec elle, le premier cas deviendrai (disons que c'est alt-c pour copy):

                          5<a-c>iXX<esc>

                          et le second

                          <a-c>3Ly3jp

                          Je dois avouer que c'est assez tentant, je vais regarder si ça peu se faire.

                          • [^] # Re: lequel

                            Posté par  . Évalué à 1.

                            Chez moi le premier exemple ne marches pas (la dernière ligne n'est correctement sélectionnée, ce qui fait que j'obtiens « aaXXaadd » au lieu de « aaaaXXdd ».

                            La copie de la selection sur la ligne suivante serais effectiment assez puissante (alt-c pour ajouter en dessous, alt-maj-C au dessus). Avec un passage en multi-curseur pour pouvoir étendre la sélection (vers la droite ou la gauche).
                            Du coup en vim « <ctrl-v>jjl » deviendrais en kakoune « <alt-c><alt-c>l »

                            Une autre remarque, quand on fait « 5X<alt-s> », on se retrouve avec 5 curseurs. Je n'ai pas trouvé le moyen (sans regarder le readme, c'est vrai) d'en sortir. Je me serais attendu à ce que plusieurs appuie sur <esc> permette d'en sortir, ou qu'un tooltip me l'indique.

                            bépo powered

                            • [^] # Re: lequel

                              Posté par  . Évalué à 0.

                              Ouaip, j'ai essayé avec C pour dupliquer la sélection sur la/les lignes suivante et <a-C> pour les precedentes, et je me suis rendu compte que ça réglait élégamment pas mal de cas que j'ai rencontré. Donc je valide, c'est pushé sur github.

                              Pour revenir a une seule selection, on fait tout simplement <space>. <a-space> fait l'inverse (garde toutes les selections sauf la principale). La sélection principale est en blanc sur bleu (par defaut) tandis que les secondaires sont en noir sur bleu. Tu peu utiliser <a-r> pour faire changer quelle sélection est la principale.

                              • [^] # Re: lequel

                                Posté par  . Évalué à 1.

                                J'ai vu ça, c'est cool ! Par contre ça ne marche pas avec des lignes trop courte. J'ai mis un commentaire sur github.

                                D'ailleurs, je voulais voir comment marchais le système d'aide, et je me suis amusé à rajouter un deuxième assistant ! C'est la première fois que je fait un pull request, donc j'espère avoir fait les choses comme il faut.

                                Pour les différentes sélections, c'est pas super évident. Je n'avais pas compris en lisant le readme à quoi sert <alt-r>. Il faudrait un peu l'expliciter à mon avis.

                                Un autre truc qui manque c'est « :map key » qui donne l'action actuellement associé à « key », ainsi que le mappage par défaut. Ça m'aurait permis de découvrir qu'en remappant « l » sur « espace » j'allais écraser quelque chose !

                                bépo powered

                                • [^] # Re: lequel

                                  Posté par  (site web personnel) . Évalué à 1.

                                  Salut,

                                  Bravo pour le cat, mais c'est pas que j'aime pas l'ascii art, mais c'est peut être l'occasion d'ajouter en option une version minimale avec par exemple juste un filet à gauche, quelque chose comme ça (c'est un U+2551) :
                                  ```

                                  ║
                                  ║
                                  ║
                                  ║
                                  ║
                                  ║
                                  ║
                                  ║
                                  ║
                                  ║
                                  ║
                                  ```

                                  • [^] # Re: lequel

                                    Posté par  . Évalué à 1.

                                    Bonjour,

                                    je regarderais la pull request quand j'aurai un peu de temps, effectivement si l'on ajoute des assistant alternatifs, j'ajouterais le support pour pas d'assistant du tout (en fait c'est déja supporté dans le code, juste pas configurable).

                                  • [^] # Re: lequel

                                    Posté par  . Évalué à 1.

                                    J'ai rajouté une proposition sur github (aucune bordure). J'ai effectué ce travail sur la branche que j'avais commencé.

                                    bépo powered

    • [^] # Re: lequel

      Posté par  . Évalué à 3.

      C'est rigolo. Moi j'utilise emacs car la première fois que je suis arrivé sous vim je n'ai réussi ni à insérer le texte que je désirais, ni à bouger le curseur et encore moins à sauver le résultat.

      Pour info, pour quitter emacs il suffit de faire
      ESC-! killall emacs

      • [^] # Re: lequel

        Posté par  (site web personnel) . Évalué à 2.

        Si emacs est dans un autre tty, on peut faire aussi :

        :! killall emacs

        Depuis le vim courant. :-)

        Tiens je remarque à l’instant que faire :!killall vim n’interrompt que les autres vim, pas le vim courant.
        Donc au delà de la blague, est-ce que ESC-! killall emacs fonctionne vraiment ?

        ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: lequel

        Posté par  . Évalué à 4.

        Que ce soit vi ou emacs, de toute façon la majorité de leurs utilisateurs qui n'ont jamais utilisé de système de plus de 20 ans (je dirais bien 30 mais j'ai peur de dire une connerie) le savent: au début on ne sait pas comment quitter et sauvegarder. Mais ça s'apprend, et une fois qu'on est à l'aise avec un éditeur puissant, je doute qu'il y ait une raison de changer.

        Maintenant, si moi j'ai choisi vim, c'est pour 2 raisons. La première, il est installé par défaut sous debian (en version allégée, certes) et la seconde c'est que les descriptions d'emacs me font penser aux «raccourcis» clavier de visual studio. Hors, les combo multi-doigt en permanence, très peu pour moi. Même dans vim il y à des trucs nécessitant des combos, mais je n'en connais pas des masses. En même temps si ça m'intéressais, je doute que j'utiliserais vim.

  • # Wiki ?

    Posté par  . Évalué à 6.

    Ça aurait pas sa place sur une page du Wiki plutôt tel que présenté ?

    • [^] # Re: Wiki ?

      Posté par  (site web personnel) . Évalué à 10.

      Tel que ce journal est présenté, je l'ai lu jusqu'à la fin en espérant enfin trouver la réponse ultime: "Quel est le meilleur éditeur de texte: Vi ou Emacs?"
      Forcément je suis un peu déçu, quelqu'un pourrait-il m'éclairer étant précisé que je ne dispose que de 5 doigts à chaque main.

      • [^] # Re: Wiki ?

        Posté par  (site web personnel) . Évalué à 1.

        étant précisé que je ne dispose que de 5 doigts à chaque main.

        Fais-toi greffer des doigts !

        Pour l'éditeur, perso, c'est vim, gvim, kate, gedit et geany. Ça dépends du contexte.

        Proverbe Alien : Sauvez la terre ? Mangez des humains !

      • [^] # Re: Wiki ?

        Posté par  (site web personnel) . Évalué à 1.

        je l'ai lu jusqu'à la fin en espérant enfin trouver la réponse ultime: "Quel est le meilleur éditeur de texte: Vi ou Emacs?"

        La question était sûrement ironique, mais je réponds quand même.

        Cette réponse n'existe bien sûr pas, mais le journal montre justement qu'il n'y a pas que vi ou emacs.

        De toute cette liste je mettrai en avant :

        • kakoune, comme expliqué un peu plus haut, je me cite moi même, "de toute la famille vi c'est le seul qui va au delà du clone et repense l'interaction avec le texte."
        • ne, pour son équilibre fonctionnalité/facilité mais je n'ai pas encore essayé de modifier sa configuration
        • Diakonos, même si il est en Ruby /o\ notamment pour son système d'aide très bien vu.

  • # RHIDE

    Posté par  . Évalué à 4. Dernière modification le 30 janvier 2015 à 02:30.

    Il y a bien longtemps (dans une galaxie lointaine, très lointaine), j'avais manipulé un clone de l'IDE Borland TurboC, sous le nom de RHIDE. Apparemment, ça utilise les composants TVision et la partie éditeur de texte (Setedit) serait compilable séparément. Je comprends qu'il existe plusieurs version de Turbo vision donc c'est un peu confus pour moi et je doute que ça compile out-of-the-box aujourd'hui, mais à l'époque (Mandrake 5, si je me rappelle bien) j'avais trouvé ça fort sympathique (je ferai un ppa si j'ai le temps un jour…)

    • [^] # Re: RHIDE

      Posté par  . Évalué à 2.

      Je me souviens avoir utilisé RHIDE sous MS-Dos (!), j'ignorais que ça existait sous Linux. Pour l'époque c'était très bien (programmation C++ avec DJGPP), mais je ne suis pas sûr que j'en dirais autant aujourd'hui.

  • # nano

    Posté par  (site web personnel, Mastodon) . Évalué à 8.

    J'utilise nano
    parce que sur un serveur en prod qui héberge 20vm ça ne le fait pas de devoir rebooter le serveur parce qu'on arrive pas à sortir de l'éditeur texte. Ok je sors --->

    Blague à part nano est simple à utiliser dans un shell et moi dans les shells c'est surtout de la retouche de fichier de configuration parfois certain script en python.

    Autrement pour coder c'est gedit, bon je suis pas un grand codeur, des scripts en python php et bash, mon petit soft domotique et c'est un peut prêt tout.

    • [^] # Re: nano

      Posté par  (site web personnel) . Évalué à 3.

      Personnellement je préfère geany pour coder vite fait en graphique, mais pour éditer rapidement en console j'utilise aussi nano.

      S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

      • [^] # Re: nano

        Posté par  . Évalué à 2.

        Statistiques personnelles pifométriques :

        • Geany 70% (hors-sujet)
        • Joe 25% (console, terminal, ssh sans X)
        • Pico 13% (je suis revenu à (re)(al)Pine pour mon courriel)
        • (G)Vi(m) 2% (dépannage, cas particuliers ; essayé de m'y mettre vraiment il y a quelques années sans y parvenir, je me contente maintenant de retenir quelques commandes de base pour la survie)
        • Emacs 0% (essayé quelques fois il y a 15/20 ans, jamais réussi à en tirer quoi que ce soit)

        • [^] # Re: nano

          Posté par  . Évalué à 6.

          Je suis impressionné de tes 110% d'utilisation.

          • [^] # Re: nano

            Posté par  . Évalué à 2.

            Note : penser à réclamer mes heures sup' :-D

            (Le pire, c'est qu'après avoir modifié mes pourcentages plusieurs fois, j'avais vérifié et revérifié le total à chaque fois, parce que je m'étais bien dit que je n'allais pas me faire avoir comme un bleu à présenter des chiffres donnant un total différent de 100, eh oh, pas de ça chez moi. Ben j'ai dû modifier une fois de plus que je n'ai vérifié… voilà, voilà…hum…)

          • [^] # Re: nano

            Posté par  . Évalué à 4.

            Peut-être qu'il utilise en fait emacs sans le savoir, qui intègre lui-même plusieurs des autres éditeurs?

  • # mined

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Il manque mined, qui est très pratique pour de l’édition de textes liée à des problèmes d’encodage en Unicode.

  • # Fte / XFte

    Posté par  (site web personnel) . Évalué à 2.

    J'ajoute FTE qui a le bon goût d'avoir une version Terminal (et aussi console) et une version X

    http://fte.sourceforge.net/
    https://packages.debian.org/sid/fte-xwindow

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Ed

    Posté par  (site web personnel) . Évalué à 10.

    Il manque le plus important: Ed

    • [^] # Re: Ed

      Posté par  . Évalué à 3.

      j'allai dire la même chose, ça ne se fait pas d'oublier ed :)

      et puis de toute façon "real programmer use emacs" http://xkcd.com/378/

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Ed

        Posté par  . Évalué à 1.

        M-x butterfly

    • [^] # Re: Ed

      Posté par  (site web personnel) . Évalué à 2.

      Ed est une horreur à utiliser avec nos consoles d'aujourd'hui (il devait être parfait du temps où la sortie "normale" d'une console était une imprimante à picots). Mais Ed a une qualité qui, à mon humble avis, semble être unique : le basculement entre le mode insertion et le mode lecture se fait par un point final. Ce qui veut dire que Ed est utilisable sur absolument tous les claviers de la planète ; même ceux des tablettes qui ne connaissent pas la touche Echap (ni les touches Fn !). Si quelqu'un connaît un éditeur de texte (sous licence libre) autre que Ed qui soit compatible avec les claviers virtuels minimalistes de tablette, je lui serais très reconnaissant.

      • [^] # Re: Ed

        Posté par  . Évalué à 2.

        Je suppose qu'il te faut configurer les binding correctement avec vim/emacs/whatever. Pour ceux qui sont en mode console, hein, pour les modes graphiques, je doute qu'il y ait besoin de t'embêter avec ça: point and click.

        Sinon, tu fais comment pour insérer un point avec ed?

        • [^] # Re: Ed

          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 02 février 2015 à 23:17.

          On comprend mieux mon propos après la lecture de ce fil de discussion du forum de ce site en date du 02/03/14.

          Il s'agissait de mon logiciel conçu pour tourner sur un ordi de bureau sous Linux et que quelqu'un a compilé le source tel quel pour le faire tourner sous Android. (Ledit logiciel tourne uniquement sur une console TTY mais il est possible d'émuler une console sous Android.) Sauf que mon logiciel qui fait obligatoirement appel à un éditeur de texte (Vi, par défaut) se trouve bloqué par l'éditeur appelé car il n'y a pas de touche échappement sur le clavier simplifié pour ces terminaux portables.

          À la suite de quoi j'ai fait une recherche sur la liste des éditeurs de texte qui seraient compatibles avec les claviers pour Android et je n'ai trouvé que Ed. (Du moins en théorie car je n'ai pas essayé pour voir si ça marchait !)

          S'agissant de la bascule insertion/lecture : Ed le fait quand on met un point tout seul sur la dernière ligne. Tout est documenté dans la page de man qui se trouve obligatoirement sur tout Unix car Ed fait fait parti de la liste des utilitaires obligatoires (Ed se trouve normalement sur toute machine Linux). Sinon, aller sur Wikipedia !

          Pour la petite histoire, l'auteur de Ed est le regretté Ken Thompson.

  • # TextAdept est cool

    Posté par  . Évalué à 2.

    TextAdept a de bonnes fonctionnalités avancées, c'est peut être celui-ci que vous devriez essayer ! (il est extensible, a une bonne auto-complétion, compilation, fenêtres splitable, multi-plateforme,…)

  • # Emacs et X

    Posté par  . Évalué à 2.

    Un petit détail à propos d'emacs. On peut désactiver le support de X à la compilation et beaucoup de distributions ont paquet pour ça, généralement emacs-nox.

  • # Les bonnes choses se perdent ?

    Posté par  (site web personnel) . Évalué à 1.

    Juste une question : j'ai l'impression que Emacs est en perte de vitesse & que Vim prend des parts de marché ?

    Un vieil utilisateur d'Emacs trop flemmard pour apprendre autre chose.

  • # neovim stable

    Posté par  . Évalué à 4.

    J'utilise nvim tous les jours depuis fin Décembre et bien, zéro soucis. Je travaille comme d'habitude, mes plugins fonctionnent comme sur vIM.
    La compilation sous Wheezy est rapide et simple, je dirais même plutôt propre, aucuns messages d'erreurs, de warning balancé à la tronche.

    Je n'ai cependant pas encore essayé les capacités de scripting Lua par rapport à l'horrible viml (vim-script), en fait, je ne sais même le support est déjà là.

  • # Un autre Vim-like

    Posté par  . Évalué à 1.

    Dans la famille Vi, on peut ajouter Vis.

  • # Designing Text Editors

    Posté par  . Évalué à 1.

    Mille mercis pour le dernier lien :-)
    La section DesigningTextEditors m'intéresse particulièrement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.