Journal Gvim moins bien que Vim ?

Posté par Dan le 18 décembre 2007 à 00:03.

Étiquettes : aucune

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) le 18 décembre 2007 à 00:20. É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 Dan le 18 décembre 2007 à 14:57. É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) le 18 décembre 2007 à 19:59. É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.
    - [^] # Re: Les boutons
      
      Posté par Dan le 18 décembre 2007 à 20:35. Évalué à 1.
      
      http://vrac.fifi.be/vimtips.txt
      
      set cmdheight=2
      
      ça marche chez moi.
# Scroll

Posté par Dies Irae (site web personnel) le 18 décembre 2007 à 00:33. É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.
- [^] # Re: Scroll
  
  Posté par Damien Lespiau (site web personnel) le 18 décembre 2007 à 02:09. Évalué à 1.
  
  Je crois que set mouse=a en plus dans ton ~/.vimrc peut marcher !
  - [^] # Re: Scroll
    
    Posté par Dan le 18 décembre 2007 à 13:08. Évalué à 1.
    
    T'es un génie !!
    set mouse=a
    marche parfaitement, merci :)
# changer de buffer sans sauvegarder

Posté par bidule le 18 décembre 2007 à 01:52. Évalué à 1.

:help hidden devrait t'y aider ...
- [^] # Re: changer de buffer sans sauvegarder
  
  Posté par Dan le 18 décembre 2007 à 13:09. Évalué à 1.
  
  Certes, mais danger il y a, un :q est si vite arrivé.
# man avec gvim

Posté par Étienne le 18 décembre 2007 à 10:30. É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 Dan le 18 décembre 2007 à 14:21. É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 Étienne le 18 décembre 2007 à 17:15. É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 Dan le 18 décembre 2007 à 18:34. É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) le 18 décembre 2007 à 19:53. É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 Étienne le 19 décembre 2007 à 12:22. É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 Philippe F (site web personnel) le 18 décembre 2007 à 11:53. É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 Aldoo le 19 décembre 2007 à 19:11. É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 Étienne le 19 décembre 2007 à 19:25. É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 Florent Bayle (site web personnel) le 18 décembre 2007 à 20:10. É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 Dan le 18 décembre 2007 à 21:30. É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 nojhan (site web personnel, Mastodon) le 18 décembre 2007 à 21:54. É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.
- [^] # Re: Avec screen
  
  Posté par nojhan (site web personnel, Mastodon) le 18 décembre 2007 à 21:57. Évalué à 1.
  
  J'oubliais, en concurrent sérieux de GVim, il ya Cream, qui est vraiment mieux foutu :
  http://cream.sourceforge.net/
  - [^] # Re: Avec screen
    
    Posté par GeneralZod le 19 décembre 2007 à 18:27. Évalué à 2.
    
    Euh, cream c'est une configuration de vim et gvim .... c'est pas un concurrent.
    - [^] # Re: Avec screen
      
      Posté par nojhan (site web personnel, Mastodon) le 23 décembre 2007 à 19:53. Évalué à 1.
      
      Certes, alors reformulons : une configuration concurrente de GVim, qui est vraiment mieux foutue.
# Ma conclusion

Posté par Dan le 21 décembre 2007 à 17:20. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.