mawww a écrit 19 commentaires

  • [^] # Re: Plug-ins

    Posté par  . En réponse à la dépêche Kakoune, un éditeur de texte qui a du caractère. Évalué à 3.

    Bonsoir,

    Oui, la completion clang est asynchrone, ctags aussi est supporté et peut generer les tags de façon asynchrone avec la commande gentags, et l'on peut sauter a la definition d'une fonction avec la commande tag.

  • [^] # Re: Plug-ins

    Posté par  . En réponse à la dépêche Kakoune, un éditeur de texte qui a du caractère. Évalué à 5.

    Kakoune dispose d'un système de complétion intégré similaire à YouCompleteMe, l'heuristique de classement des mots demande encore un peu de peaufinage, mais la fonctionnalité est la. Lorsque on est en mode d'insertion, les mots disponible dans les tampons ouverts sont proposé comme complétion. Le script clang.kak rajoute quand a lui la completion intelligente pour C/C++/Objective-C, et aussi les diagnostiques automatiques à la Syntastic.

    Pour activer la complétion pour les fichier C, ainsi que les diagnostiques, on peut mettre le code suivant dans son kakrc:

    hook global WinSetOption filetype=cpp %{
        clang-enable-autocomplete
        clang-enable-diagnostics
    }
    
  • [^] # Re: Plus rapide ?

    Posté par  . En réponse à la dépêche Kakoune, un éditeur de texte qui a du caractère. Évalué à 5.

    Il faut comprendre que ça n'est pas une nouvelle syntaxe, Il n'y a pas de concept de remplacement de regex du tout dans Kakoune, uniquement celui de sélection de regex. La substitution viens de la combinaison de plusieurs fonctionnalités:

    • La sélection de regex avec s, qui ouvre un prompt, dans lequel on tape une regex (ou l'on peut aussi rappeler une regex précédente via l'historique). Avec la recherche incrémentale, les matches sont visible au fur et a mesure que l'on tape l'expression.
    • Le mode d'insertion, qui permet de remplacer ces selections, avec access au groupes de captures via les registres 0..9. Ici on y rentre avec c pour supprimer le contenu des sélections avant (exactement comme vim ferait avec cw)

    Les regex, au passage, utilise la syntaxe perl (boost::regex en pratique, mais très proche de pcre).

  • [^] # Re: Difficulté d'apprentissage

    Posté par  . En réponse à la dépêche Kakoune, un éditeur de texte qui a du caractère. Évalué à 10.

    Clairement, Kakoune requière un apprentissage pour devenir efficace.

    Du point de vue d'un Emacsien, il n'est pas un meilleur Emacs, loins de la, car il se concentre plus sur l'interaction avec l’environnement extérieur que la programmabilité de ses comportements internes.

    Pour un Vimiste, il dépends bien entendu de son point de vue. A mon sens Kakoune est un meilleur vim pour différentes raisons:

    • Plus rapide que vim: dans le sens moins de touches à taper pour le même résultat (voir mes exemples vimgolf)
    • Plus simple que vim: les responsabilités des différents modes sont mieux respectés, les commandes interagissent beaucoup plus facilement les unes avec les autres.
    • Plus interactif que vim: l'inversion de la sélection et de la commande, outre permettre la composition des sélections, permet d'afficher incrémentalement ceux sur quoi l'on va agir. Le modèle d'extension rends l’a-synchronicité facile, les commandes grep et make par exemple tournent en tache de fond, avec leur sortie remplissant progressivement un tampon.
    • Plus facile à apprendre: Kakoune essaie un maximum de fournir de l'aide en direct. Par defaut chaque commande dans le prompt affichera sa documentation, les commandes comme g qui attendent une seconde touche affichent aussi les possiblités. On peut même, en mettant l'option autoinfo à 2, obtenir une aide qui explique apres chaque touche en mode normale ce qu'il viens de se produire.

    Enfin, en respectant la vision "les touches appuyés forment un language d'edition de texte", Kakoune est en passe de remplacer sed (pour moi) pour les editions rapides, car il me permet d'exprimer plus concisement des changement plus complexe. (Kakoune peut etre utilisé comme un filtre avec 'kak -f', par exemple echo tchou | kak -f 'sou<ret>caa' est equivalent à echo tchou | sed -e 's/ou/aa/g'

  • [^] # Re: Plus rapide ?

    Posté par  . En réponse à la dépêche Kakoune, un éditeur de texte qui a du caractère. Évalué à 9.

    Bonjour,

    c'est une touche de moins (le : requis dans vim avant le %), mais le gros avantage reste que c'est incrémental, on voit la sélection et on utilise le mode d'insertion normal. L'autre aspect, c'est que c'est composable, tu peu par exemple faire %sfoo(msbard qui va selectionner les matches de foo(, puis selectionner le contenu des parenthese apres le foo (le 'm' fait ce que la touche '%' fait dans vim), puis selectionner bar dans ces selections et le supprimer (avec 'd'), ce qui permet d'exprimer la suppression de tout les 'bar' dans les parametres de 'foo' (comme exemple).

  • [^] # Re: lequel

    Posté par  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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  . En réponse au journal Tour d'horizon des éditeurs de texte pour le terminal. É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.