Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 27/07/2011, à 20:10

djipey

Vim: quelques questions

Bonsoir.

Je cherche à me perfectionner avec Vim, et là actuellement je me pose 2-3 questions:

-Est ce qu'il y a moyen de sauvegarder plusieurs fichiers en même temps? (genre on code un script en python, avec ses modules ouverts, et on veut lancer le script. Pour ça, il faut aussi que les modules aient été sauvegardés pour que le script prenne en compte les modifications).

-Est ce que c'est possible d'assigner une fonction "tout sauvegarder puis lancer le script" à une touche raccourcie?

-Est ce que Vim fait des auto-sauvegarde? Je sais qu'il a un genre de buffer qui contient le fichier que l'on est en train de modifier, mais si par exemple il y a une coupure de courant, est ce qu'il garde tout en mémoire?

Voilà voilà. Des questions bêtes mais qui ont leur utilité. Merci à vous.

Dernière modification par djipey (Le 29/07/2011, à 19:44)

Hors ligne

#2 Le 28/07/2011, à 10:08

Luc Hermitte

Re : Vim: quelques questions

Hello.
Dans l'ordre.

a- :h :wall

b- Oui.

" mapping à mettre dans un ftplugin python -> ~/.vim/ftplugin/python/ta_config.vim
nnoremap <buffer> <c-f5> :wall<cr>:!python %:p<cr>

" voire, si tu travailles sur un projet multi fichiers
nnoremap <buffer> <c-f5> :wall<cr>:!python <c-r>=b:project_main<cr><cr>

La variable locale aux buffers b:project_main pouvant être positionnée avec un des nombreux plugins local_vimrc: <pub>http://code.google.com/p/lh-vim/source/ … _vimrc.vim</pub>.

Après on peut aller plus loin pour faire de la détection automatique de nom de projet pour supporter implicitement les petits projets mono-fichier, et permettre de configurer quel nom d'exécutable utiliser sinon.
C'est le genre de chose que j'ai faite dans BuildToolsWrapper -> http://code.google.com/p/lh-vim/source/ … er.vim#611

c- C'est possible, mais je ne garantis rien. Il y a des fichiers .swp qui sont censés être utiles pour faire de la récupération après plantage, je n'ai jamais réussi à en tirer quoique ce soit d'intéressant. Du coup, je sauvegarde régulièrement depuis. (et j'ai investi dans un onduleur...)

HTH.

Hors ligne

#3 Le 28/07/2011, à 18:21

djipey

Re : Vim: quelques questions

Ok.

Merci pour le wall. Par contre je n'ai pas tout compris.

Au sujet de b):

" mapping à mettre dans un ftplugin python -> ~/.vim/ftplugin/python/ta_config.vim
nnoremap <buffer> <c-f5> :wall<cr>:!python %:p<cr>

Pourquoi mets-tu ça dans un fichier particulier et pas dans le vimrc? Quels sont les avantages?

Et:

" voire, si tu travailles sur un projet multi fichiers
nnoremap <buffer> <c-f5> :wall<cr>:!python <c-r>=b:project_main<cr><cr>

Ça ça va tout sauvegarder et lancer le script, et b:project_main sert à déterminer quel est le fichier principal, c'est ça ou je suis à côté de la plaque?

Et est ce que tu pourrais détailler un peu ceci:

Après on peut aller plus loin pour faire de la détection automatique de nom de projet pour supporter implicitement les petits projets mono-fichier, et permettre de configurer quel nom d'exécutable utiliser sinon.

Je ne comprends pas bien. Cela voudrait dire que le mapping d'au dessus  ne détermine pas quel est le fichier à lancer?

Et pour c), c'est plus de la paranoia qu'autre chose, je sauvegarde maladivement à chaque ligne que j'écris. Mais j'ai trouvé 2-3 pistes pour les sauvegardes toutes les x minutes.

Globalement, je pose beaucoup de question, mais devant le détail de ta réponse je me dis que tu peux m'apprendre des trucs. Merci à toi.

Hors ligne

#4 Le 28/07/2011, à 18:47

Luc Hermitte

Re : Vim: quelques questions

Tout ce qui est spécifique à un langage donné va dans des ftplugins du dit langage. Et pas dans le vimrc.
Le vimrc c'est pour des trucs globaux valables pour tout type de fichier.

b.1-  Le ctrl-f5, tu peux vouloir l'avoir pour du python, pour du C, pour du java, pour du perl, et à chaque fois le comment on lance sera différent. (sauf si les shebang (#!/bin/sh, etc) de tes scripts marchent -- il n'est pas rare que d'un système à l'autre je rencontre des soucis de portabilité quant à l'endroit où est installé un interpréteur donné). Et pour avoir une conf différente à chaque fois, il faut disposer de définitions propres à chaque buffer (:h map-<buffer>), et cela se fait dans des ftplugins (ou à coup d'autocommandes, mais on sent vite la limite à cela au boulot de quelque centaines de lignes de code et de 2-3 types de fichiers différents).

NB: le vimrc est chargé une seule fois, un ftplugin est chargé une fois par buffer dont le type correspond au ftplugin.

b.2- C'est ça (pour b:project_name (qui est une variable locale à un buffer))

b.3- Quand je code, j'ai deux types de projets:
- des vrais projets de plusieurs centaines de fichiers, mais pour lesquels j'ai un makefile avec sa cible qui va bien, et un exécutable au final)
- des pet-projets qui me permettent de tester de bouts de codes, des trucs étranges, etc. Ils sont mono-fichier. Et au final, j'ai un exécutable par fichier source.

Et je ne veux pas m'embêter : vim doit être capable de reconnaitre dans quel cas je suis sans avoir à spécifier 150000 choses. C'est là que les heuristiques de mon plugin BTW interviennent (en version simple ->) :
- s'il existe une variable g/b:project(_executable), j'utilise ce nom pour lancer le binaire
- sinon, c'est un projet mono-fichier, et BTW sait les compiler sans makefile (merci GNU make!), et il sait quel binaire exécuter au final.

Par contre, je passe par un autre mapping plus "complexe" que celui que j'ai donné dans le forum -- cf le code source du plugin pour voir comment ça marche.

Hors ligne

#5 Le 28/07/2011, à 21:33

djipey

Re : Vim: quelques questions

D'accord, habile le coup du ftplugin (pourquoi ce nom d'ailleurs?), du coup je vais devoir changer quelques trucs, j'avais par exemple mappé F5 pour compiler mon code latex.

Voyons si j'ai bien compris le coup des variables:

Il existe une variable b:project_name locale à chaque buffer. Si ce n'est pas le fichier principal (genre un header en C), cette variable vaut quelque chose. Si c'est le fichier principale, elle vaut b:project_main. C'est Vim qui est capable de faire la différence? Il regarde qui est inclus dans qui pour faire ça?

Et au final, je ne code que des petits projets, qui ne font pas plus de 5-6 fichiers en général, et j'utilise de plus en plus de langages scriptés. J'aimais bien le C, mais comme je ne code qu’occasionnellement, je lui préfère python qui est plus simple. Aussi est ce que ton mapping pourrait me convenir, quitte à ce que j'installe ton plugin si je dois m'atteler à des projets plus complexes?

Hors ligne

#6 Le 28/07/2011, à 23:40

Luc Hermitte

Re : Vim: quelques questions

ftplugin, c'est pour filetype plugin. C'était la grande nouveauté de Vim 56 smile

Cette variable, c'est à toi de la positionner -- et de l'appeler comme il te plaira. Vim, de base, il ne sait pas le faire.
Tu pourrais utiliser une variable globale, mais du coup, si tu ouvres des fichiers de plusieurs projets, comment pourrais-tu dire à vim lequel exécuter. c'est pas possible. D'où qu'en buffer-local c'est mieux.

Comment faire ? Plusieurs possibilités
- à la main, mais on sent vite les limites
- avec des autocommandes dans le .vimrc qui reconnaissent des morceaux de chemin (pas pratique quand on transfère les fichiers d'une machine à l'autre si on n'a pas la même organisation, ou si on les déplace)
- Avec le plugin "project". Là il faut lire la doc, ça fait des lustres que je n'y ai plus touché.
- Avec un des 10 plugins qui s'appelle local_vimrc. J'en ai un moi-même. Il faut alors définir un fichier _vimrc_local.vim à déposer à la racine de chaque projet multi-fichiers. Il contiendra l'affectation

:let b:project_main = 'toto.py'

Et après, il faudra définir tes mappings pour exploiter cette variable. Ex:

" {rtp}/ftplugin/python/automagic_exec.vim
" Je te passe tous les gardes anti-réinclusion car je tape au fil de l'eau 
" sans passer par mes wizards
nnoremap <buffer> <c-f5> :call <sid>Execute()<cr>

function! s:Execute()
    if     exist('b:project_main') | let e = b:project_main
    elseif exist('g:project_main') | let e = g:project_main
    else                           | let e = expand('%:p')
    endif
    " pour bien faire, il faudrait détecter automatiquement si python est bien
    " installé,  ou alors permettre de le retrouver, ou d'exploiter la shebang, etc...
    " voire faire un truc plus générique pour tout type de langage de script
    exe '!python '.e
endfunction

Mon plugin ne te servira pas à grande chose. Il est très orienté compilation et exploitation des erreurs de compil. En bonus, il sait lancer un exécutable qu'il reconnaitra automagiquement en l'absence de détails, et même lui passer des paramètres d'exécution.
Des principes de son implémentation sont réutilisables, mais c'est tout ici.

Dernière modification par Luc Hermitte (Le 29/07/2011, à 00:20)

Hors ligne

#7 Le 29/07/2011, à 07:46

djipey

Re : Vim: quelques questions

D'accord. Merci pour tes conseils et tes précisions. C'est surement beaucoup trop détaillé pour moi, mais ça pourra me servir un jour.

Aujourd'hui comme mes projets sont petits, je vais utiliser simplement ça:
nnoremap <buffer> <c-f5> :wall<cr>:!python %:p<cr>

Que je lancerai à partir du fichier principal. Le jour où j'aurai besoin de quelque chose de plus perfectionné, j'installerai le plugin project.

Merci à toi en tout cas, ça m'a été bien utile.

Hors ligne

#8 Le 02/09/2011, à 22:37

djipey

Re : Vim: quelques questions

Bonsoir.

Et bien voilà, c'est arrivé, j'ai besoin de plus perfectionné. C'est vraiment chi**t de devoir ce remettre dans le bon portview quand on lance un programme qui dépend de plusieurs fichiers, que l'on modifie à partir de d'autres portviews.

Est ce qu'il y a moyen de lancer le programme principal à partir des portviews secondaires avec le plugin project? J'ai lu sa description sur le site, mais rien qui indique comment lancer le script de n'importe où.

Hors ligne

#9 Le 05/09/2011, à 12:56

Luc Hermitte

Re : Vim: quelques questions

Je n'ai pas la moindre idée de ce dont tu parles. C'est quoi un portview pour toi ?
(Dans le jargon vim, il y a fichier, buffer, window, et tab)
Sinon, je n'utilise (toujours) pas le plugin project, et je vais avoir du mal à t'aider (avec ce plugin)

Hors ligne

#10 Le 05/09/2011, à 18:30

djipey

Re : Vim: quelques questions

C'est viewport, pardon. En fait c'est quand tu splittes ton écran. Par exemple si je le splitte en 2 verticalement avec :vsp, j'ai le viewport de gauche, et viewport de droite.
Ensuite l'intérêt c'est que dans chaque viewport, tu édites un fichier différent. Mais bon je pense que tu sais ce que c'est, c'est juste le nome qui ne va pas.

Du coup le problème c'est qu'avec ça, quand dans un viewport tu édites un fichier secondaire (qui n'est donc pas l'éxécutable du dossier), il faut revenir sur le bon viewport pour lancer le script.

Est ce que j'ai été clair?

Hors ligne

#11 Le 06/09/2011, à 14:16

Luc Hermitte

Re : Vim: quelques questions

OK. C'est window le terme. Pas viewport.
Il n'y a pas de réponse simple.
Quand dans une seconde fenêtre j'ouvre un fichier qui appartient à un autre projet (répertoire), ma config (local_vimrc + BTW dont j'ai parlé plus haut) fait que la projet courant devient celui de la fenêtre dans laquelle je me trouve.
Si c'est un autre fichier du même projet, il est facile de le rattacher au même projet avec des outils comme local_vimrc (et probablement avec projet, que je n'utilise pas donc). Si c'est un fichier qui vient complètement d'ailleurs (autre hiérarchie/fichier temporaire pour un vimdiff depuis le HEAD d'un repository/...), cela devient vite beaucoup plus compliqué. On peut s'amuser à dire que les info du projet sont définies par une variable globale, mais ce n'est pas très propre, et c'est vite bourré d'effets de bords. Un fois de plus, il va falloir passer par local_vimrc (et peut-être project) pour faire de la mise à jour automatique de la variable globale sur changement de répertoire/projet.

Hors ligne

#12 Le 08/09/2011, à 14:30

djipey

Re : Vim: quelques questions

Ok.

J'ai installé ton plugin, j'ai crée un fichier _vimrc_local.vim dans lequel je fais:

:let b:project_main = 'allocine.py'

function! s:Execute()
    if     exist('b:project_main') | let e = b:project_main
    elseif exist('g:project_main') | let e = g:project_main
    else                           | let e = expand('%:p')
    endif
    " pour bien faire, il faudrait détecter automatiquement si python est bien
    " installé,  ou alors permettre de le retrouver, ou d'exploiter la shebang, etc...
    " voire faire un truc plus générique pour tout type de langage de script
    exe '!python '.e
endfunction

nnoremap <buffer> <F6> :call <sid>Execute()<cr>

Et j'ai cette réponse:

Erreur détectée en traitant function <SNR>33_Execute :
ligne    1 :
E117: Fonction inconnue : exist
E15: Expression invalide : exist('b:project_main') | let e = b:project_main
ligne    8 :
E121: Variable non définie : e
E15: Expression invalide : '!python '.e

Le code que tu m'as donné un peu plus haut, c'est juste l’algorithme ou la syntaxe est bonne aussi? (je ne connais vraiment pas grand chose à la syntaxe de vim).

Hors ligne

#13 Le 08/09/2011, à 15:54

Luc Hermitte

Re : Vim: quelques questions

C'était du code tapé de mémoire. La fonction est exists() (:h exists())
NB: pour bien faire il faudrait rajouter des gardes anti-réinclusion. Bien faire au sens: ne pas tout recharger à chaque fois.

Sinon, ton besoin m'a donné des idées pour aller plus loin avec local_vimrc et BTW et définir une notion de projet principal (le premier chargé) et secondaires (les autres qui viendraient ensuite), et la possibilité de passer d'un projet à l'autre. Je vois ce qu'il faut faire mais malheureusement je ne vais pas avoir le temps avant un bon moment. sad

Hors ligne

#14 Le 08/09/2011, à 18:13

djipey

Re : Vim: quelques questions

C'est bon, ça marche nickel comme ça. J'ai enfin ce que je veux.

Par contre je n'ai pas bien compris ton histoire de réinclusion. Qu'est ce qui peut être réinclus?

Quant à l'amélioration de ton plugin, je me demandais à quoi pouvait servir de définir un projet "principal" et des projets "secondaires". Les gens créent en général un répertoire pour chaque projet, non? Avec des sous-répertoires pour leurs classes, les fichiers de conf, de sauvegarde, etc. Avec ton système de _vimrc_local, qu'il suffit de placer à la racine de chaque projet, on est déjà bien opérationnel. Mais je n'ai peut être pas compris ce que tu voulais dire.

Hors ligne

#15 Le 08/09/2011, à 19:15

Luc Hermitte

Re : Vim: quelques questions

À chaque fois que tu vas mettre le focus sur une fenêtre de ton projet, le fichier _vimrc_local.vim va être rechargé (mets un <<:echomsg "encore!">> pour t'en rendre compte)
La bonne façon est d'utiliser des gardes anti-réinclusion. Cf les commentaires en début de fichier -- N.B.: mu-template génère automatiquement les squelettes vides de fichier _vimrc_local avec les vérifications qui vont bien.

Pour l'idée derrière le projet secondaire : Si tu charges un fichier d'un autre projet pour voir comment une fonction est réalisée afin de la copier. Si tu exécutes (/compile) depuis la fenêtre de ce fichier "externe", quel est le comportement attendu?
a- exécuter/compiler le projet en cours d'édition jusqu'à présent
b- exécuter/compiler le projet correspondant à la fenêtre courante ?
Avec le fonctionnement courant, c'est b- qui se passe.

Autres cas particuliers, un diff avec un scratch-buffer qui contient une révision autre du fichier qui se trouve sur un repository (git, svn, etc). L'exécution du projet, devrait bien correspondre au projet courant. Hors le scratch-buffer ne déclenche pas le chargement de _vimrc_local.
Même problème depuis la fenêtre quickfix contenant les résultats de compilation -- que j'ai résolu avec des feintes pour BuildToolsWrapper.
Pour ces cas particuliers, la notion de projet courant (en variable globale) a énormément de sens.

Hors ligne

#16 Le 08/09/2011, à 19:20

djipey

Re : Vim: quelques questions

D'accord. Tu as des besoins beaucoup plus spécifiques que moi en fait.

En tout cas merci pour ton aide, j'ai ce que je voulais. Bonne soirée à toi.

Hors ligne

#17 Le 08/09/2011, à 19:42

Luc Hermitte

Re : Vim: quelques questions

Avec plaisir.
Bonne soirée à toi aussi.

Hors ligne