Journal Gvim moins bien que Vim ?

Posté par  .
Étiquettes : aucune
0
18
déc.
2007
-----------------
J'avais fini mon dernier journal par ça :
Prochain journal en mode mavie : testdisk & photorec (pour la récupération de fichiers/partition)
Mais finalement, on trouve de plus en plus de tutoriaux dessus et l'utilisation de ces logiciels est plutôt simple, alors j'ai abandonné au profit d'un constat que j'ai récemment fait sur vim et l'intérêt du graphique.
-----------------

J'utilise depuis quelques temps Gvim et j'en suis assez satisfait.
Je lance un serveur et tout ce que j'ouvre arrive sur la même fenêtre, grâce à la commande :
gvim --servername Danou --remote-silent-tab mon_fichier
Mais plus le temps passe, plus j'utilise de fonctions vim.
Surtout les deux suivantes :
-le shell : soit avec :!commande soit avec :sh[ell] qui lance un nouveau shell.
-La touche K qui permet de lancer le man du mot sous le curseur.

Et là, petit problème avec Gvim : son support de shell est minime, il n'est pas capable d'afficher des couleurs et encore moins une manpage correctement. Peut-être y a t-il une astuce qui permet de faire tout ça, mais par défaut, ça foire complètement.
Alors là, je reviens sous Vim en console, et je me rends compte qu'on peut toujours se servir des tabs et du serveur pour toujours ouvrir dans la même fenêtre tous les fichiers, et tout ça, bien plus rapidement qu'en graphique.
Mais problème : pour naviguer entre les tabs, il faut taper :tabn ce qui est bien plus long qu'avec les registres avec la combinaison :bn pour changer.
Bon... Les tabs ont cet avantage sur les registres qu'il n'est pas utile de sauvegarder avant de changer de fichier, de plus l'historique des modifications est conservé, alors que quand on change de registre, on peut plus annuler les opérations que l'on avait faites.

Alors petit à petit on s'habitue à :tabn donc pas de soucis, surtout qu'il y a déjà un raccourci qui permet de changer d'onglet définit par défaut :
gt correspond à :tabn
gT correspond à :tabp

Et au pire, on peut toujours définir un raccourci dans le .vimrc.

La création d'un nouvel onglet avec :tabnew n'a pas de raccourci alors on peut en définir un dans le .vimrc. J'ai choisi F2 :
map ‹F2› :tabnew‹cr›
(désolé pour le copier coller qui marchera pas)

Donc pour l'instant, tout ceci marche pareil entre vim et gvim sauf que vim est (beaucoup) plus rapide et affiche mieux le shell.
Le seul truc qui pourrait manquer à vim par rapport à gvim, ce serait de pouvoir scroller avec la souris pour les fichiers qu'on veut juste voir sans modifier. La molette reste plus pratique quand on veut juste lire qu'un ‹C-e› ‹C-y› ou ‹C-f› ‹C-b› ou ‹C-d› ‹C-u›.

-----------------

Ensuite, vient le choix du terminal, très important, qui va beaucoup influer sur la qualité et la vitesse de vim.
J'ai choisi urxvt car il est rapide (plus qu'un xterm) et supporte l'unicode.
J'utilise cette commande :
urxvt -fn "xft:Bitstream Vera Sans Mono:pixelsize=20" -bg black -fg white +sb -e vim --servername Danou --remote-silent-tab mon_fichier
Ça utilise une belle police de caractère, assez grande pour être lisible. Ça ralentit un peu le terminal, mais c'est vraiment plus beau, et puis ça reste un terminal, donc c'est rapide.
Le fond noir et l'écriture blanche : là, c'est un choix, on peut préférer l'inverse.
Pas d'ascenseur inutile.

Vient le dernier paramètre qui lance vim s'il n'est pas lancé, ou alors ouvre un onglet dans le vim existant s'il est déjà lancé.
Ce comportement est presque idéal et se rapproche finalement de beaucoup d'éditeurs graphiques.
Bien sûr on pourrait, selon les fichiers, ouvrir un serveur vim différent, avec un fichier .vimrc différent.

-----------------

Le problème de l'option -e des terminaux graphiques avec cette utilisation.

Avec la commande utilisée, Vim s'ouvre dans le terminal directement, il n'y a donc pas de shell derrière, donc si on fait ‹C-z› on se retrouve avec rien derrière et on doit faire ‹C-c› pour revenir sur vim.
Bien sûr, :sh permet d'ouvrir un shell de manière identique, mais ça prend du temps à s'ouvrir alors qu'un ‹C-z› est immédiat (et fg pour revenir après).
Pour ce léger problème, je suis sûr qu'une solution simple existe, et je m'en remet un peu à vous.

-----------------

Finalement, la régression transition du graphique vers la console n'a été que favorable, et mis à part le scrolling qui pourrait manquer de temps en temps, et le ‹C-z› qui ne me remet pas sur le shell quand j'ouvre mon vim avec la session dans mon urxvt, je dois dire que rien ne manque.
Même la sélection qui doit se faire au clavier n'est pas gênante.
Donc je terminerai sur une question.

En quoi une version graphique IMprove vim ? Ou en tout cas, en quoi le graphique pourrait l'améliorer, si ce n'est pour les menus et la souris ?
(oui, ça fait deux questions)
  • # Les boutons

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

    Pour gvim, il y a bien sur les boutons ! Et évidemment, plus de couleurs. Et les sélecteurs de fichiers aussi.

    Sérieusement, il y a deux choses pour lesquelles je préfère gvim : quand je lance une commande, malgré le quiet (ou silent, je ne sais plus), vim me demande une confirmation que gvim ne demande pas ; et j'utilise un système sous lequel vim n'a pas de mode serveur, alors je simule le truc avec des applescripts qui tape ce qu'il faut dans la fenêtre qu'il faut, mais pour que ça marche, il faut qu'il trouve l'application et la bonne fenêtre, alors dans les multiples terminaux, ça ne marche pas.

    Pour les tabs, je ne m'y fais pas. J'ai pourtant mis les mêmes raccourcis clavier que dans mon navigateur, mais je préfère les buffers.

    Et si j'ai besoin d'un vi rapide avec des fonctions évoluées, j'utilise elvis. (qui serait parfait s'il prenait en compte les encodages)
    • [^] # Re: Les boutons

      Posté par  . Évalué à 1.

      Pour l'avantage des boutons, des couleurs et du sélecteur de fichier, j'imagine bien l'ironie qui est tienne.

      Mais pour la deuxième partie, je ne comprends pas...
      :!ls dans vim ou gvim me sort le même résultat (sauf que dans gvim, on est toujours sur le même écran dans l'endroit où c'est affiché). On ne me demande pas de confirmation, alors je capte pas trop ce que tu voulais dire.

      Donc alors, il n'y a vraiment pas de sérieux argument en faveur du graphique ?
      • [^] # Re: Les boutons

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

        En fait, quand je fais :make, j'ai un "Press ENTER or type command to continue" dans vim, mais pas dans gvim (avec un autre .vimrc, j'ai soit 2 soit une fois ce message suivant le g ou non). Mais je suppose que c'est un défaut de configuration.
  • # Scroll

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

    Pour le defilement a la souris ca a l'air de dependre du terminal: j'utilise gnome-terminal et je scrolle sans probleme dans vim a la souris.
  • # changer de buffer sans sauvegarder

    Posté par  . Évalué à 1.

    :help hidden devrait t'y aider ...
  • # man avec gvim

    Posté par  . Évalué à 1.

    Pour lire les manpages avec gvim (ou vim d'ailleurs), il y a le plugin man (fournit de base) (:help Man)

    En gros tu peux faire :
    :runtime ftplugin/man.vim

    Puis

    :Man ls

    Et l'ecran se split horizontalement et te permet de lire la page de man directement avec vim et une belle coloration syntaxique.


    Etienne
    • [^] # Re: man avec gvim

      Posté par  . Évalué à 1.

      Génial !
      Juste un truc : j'imagine que tu as fait en sorte que ton 'K' se serve de :Man plutôt que le man par défaut.
      T'as fait comment ? Parce que modifier keywordprg n'a pas l'air d'être la solution, puisque ça use une commande externe...
      • [^] # Re: man avec gvim

        Posté par  . Évalué à 2.

        Juste un truc : j'imagine que tu as fait en sorte que ton 'K' se serve de :Man plutôt que le man par défaut.

        C'est prévu dans le plugin, mais ça utilise <Leader>K :


        if exists(":Man") != 2
        com -nargs=+ Man call s:GetPage(<f-args>)
        nmap <Leader>K :call <SID>PreGetPage(0)<CR>
        endif


        Par défault, est définit à \, il faut donc utiliser \K, ce qui n'est pas pratique sur un clavier français. On peut trouver deux solution :
        - modifier plugin man.vim pour mapper K sur PreGetPage(0) avec noremap.
        - définier mapleader à un charactère plus accessible avant de charger le plugin, par exemple dans ton vimrc

        let mapleader=","
        runtime ftplugin/man.vim
        et du coup le man devient accessible avec ,K.
        • [^] # Re: man avec gvim

          Posté par  . Évalué à 1.

          :)
          Bon, je crois que je vais garder le \ par défaut, parce que je me sers des fois de la virgule...

          Sinon, c'est assez génial, je ne pertinente pas parce que ça marche pas (ça appuie, mais ça change rien), mais le coeur y est.
          • [^] # Re: man avec gvim

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

            Ce qu'il y a , c'est que normalement, après une virgule, tu mets une espace, donc ça ne gène pas (contrairement à l'antislash si tu fais du latex genre).
          • [^] # Re: man avec gvim

            Posté par  . Évalué à 1.

            Bon, je crois que je vais garder le \ par défaut, parce que je me sers des fois de la virgule...

            Tu peux très bien faire en sorte qu'il n'y ai que pour le ,K que ca soit le cas en faisant :

            let mapleader=","
            runtime ftplugin/man.vim
            let mapleader="" "restoration du comportement par défaut

            Tu peux mettre ce que tu veux dans mapleader et ce ne sera utilisé que par ce qui est définit dans man.vim

            Etienne
  • # Les touches du curseur ne servent à rien

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

    Si t'es un vrai utilisateur de vim, tu n'utilises que jhkl pour te déplacer dans ton fichier. Il te reste donc des touches avec des flèches qui ne servent à rien.

    Chez moi, elles sont remappées :
    - :bp
    - :bn
    - :cp
    - :cn

    et hop, se déplacer d'un fichier à un autre est tout de suite plus rapide.
    • [^] # Re: Les touches du curseur ne servent à rien

      Posté par  . Évalué à 2.

      Il n'y a pas un "considered harmful" pour les raccourcis claviers basés sur la géométrie des touches alphabétiques du clavier ?
      Parce que jhkl en dvorak... ahem !

      Les flêches de direction sont faites pour cela, et ne sont pas supposées être remappées dans les configurations de clavier "normales".

      Je comprends qu'à une certaine époque, certains terminaux aient eu du mal avec les touches "spéciales"... mais là, à part l'habitude, je ne vois pas trop en quoi ce serait une bonne pratique de continuer à utiliser jhkl.

      Du coup, si les touches jhkl sont libres, ça tombe bien, on peut donc les réutiliser pour d'autres fonctions !
      • [^] # Re: Les touches du curseur ne servent à rien

        Posté par  . Évalué à 1.

        Je comprends qu'à une certaine époque, certains terminaux aient eu du mal avec les touches "spéciales"... mais là, à part l'habitude, je ne vois pas trop en quoi ce serait une bonne pratique de continuer à utiliser jhkl.


        Ca permet surtout de garder les mains sur la partie alphabétique du clavier et ca fait donc moins de mouvement.
        Je comprend volontier qu'on trouve ça un peu bizarre comme justification mais à l'usage, c'est quand même plus ergonomique (je n'ai pas dit intuitif).


        Etienne
  • # Navigation entre les tabs

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

    Pour passer d'une tab à l'autre, tu as Ctrl+PageUp et Ctrl+PageDown. Tu aurais pu le trouver par toi-même avec :help tabn.
    Même chose pour la molette : :help mouse. Par exemple, tu peux faire un :set mouse=n pour te servir de la molette en mode normal (ce qui te laisse la possibilité de faire des sélectionner-coller avec la molette en mode insertion, par exemple).
    • [^] # Re: Navigation entre les tabs

      Posté par  . Évalué à 1.

      ouais, ça m'arrivait de m'en servir avec gvim... Mais honnêtement, je trouve ça nul.
      gt est bien plus simple. Je l'avais vu avec :help tabn d'ailleurs.

      Mais c'est vrai que j'ai pas pensé à faire :help mouse ^_^
  • # Avec screen

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

    Sinon, pour une bonne combinaison, on peut utiliser vim sous screen, c'est très pratique, même en local. Tu as le scrolling au clavier, le split, les tabs, ... un environnement très "command-line-friendly" avec en prime la possibilité de lancé tout et n'importe quoi, de détacher les processus à la volée, donc sans perdre de session si c'est en distant.

    Bref, que du bon, il faut juste choisir qui de vim ou screen va gérer les fonctionnalités redondante, c'est affaire de goût.
  • # Ma conclusion

    Posté par  . Évalué à 1.

    Déjà mon problème sur le démarrage a été résolu par Etienne ici :
    https://linuxfr.org/forums/26/23717.html

    Ensuite, entre vos commentaires et ce que je connais de Vim, c'est l'écrasante victoire de VIM sur Gvim :
    - Tout ce que fait Gvim, Vim le fait
    - Vim a la souplesse d'un shell
    - Gvim a en plus des boutons et des menus.


    Le choix est vite fait ^_^

Suivre le flux des commentaires

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