Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de Danou :
- [26/08@13:33] Disque durs USB et anciens bios
- [08/02@14:15] Des astuces pour Rox-Filer.
Journal : Gvim moins bien que Vim ?
Posté par Dan () le 17 décembre 2007J'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_fichierMais 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 à :tabpEt 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)
> Lire le journal (25 commentaires, moyenne: 1,2).
Les boutons
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/12/2007 à 13:57. (lien). É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 Ernest H (Jabber id, ) le 18/12/2007 à 18:59. (lien). É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/12/2007 à 19:35. (lien). Évalué à 1.http://vrac.fifi.be/vimtips.txt
set cmdheight=2
ça marche chez moi.
-
-
Scroll
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 () le 18/12/2007 à 01:09. (lien). Évalué à 1.Je crois que set mouse=a en plus dans ton ~/.vimrc peut marcher !
-
[^]Re: Scroll
-
man avec gvim
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/12/2007 à 13:21. (lien). É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 Etienne () le 18/12/2007 à 16:15. (lien). É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
et du coup le man devient accessible avec ,K.
let mapleader=","
runtime ftplugin/man.vim
-
[^]Re: man avec gvim
Posté par Dan () le 18/12/2007 à 17:34. (lien). É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
-
[^]Re: man avec gvim
Posté par Etienne () le 19/12/2007 à 11:22. (lien). É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
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 (Jabber id, ) le 19/12/2007 à 18:11. (lien). É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 Etienne () le 19/12/2007 à 18:25. (lien). É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
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
Avec screen
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 Noj Han (Jabber id, page perso, ) le 18/12/2007 à 20:57. (lien). É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/12/2007 à 17:27. (lien). Évalué à 2.Euh, cream c'est une configuration de vim et gvim .... c'est pas un concurrent.
-
[^]Re: Avec screen
Posté par Noj Han (Jabber id, page perso, ) le 23/12/2007 à 18:53. (lien). Évalué à 1.Certes, alors reformulons : une configuration concurrente de GVim, qui est vraiment mieux foutue.
-
-
Ma conclusion
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 ^_^
Cette page a été générée par Templeet en 0.1063s (dont 0.0147 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.