Vim : appliquer les paramètres sur les fichiers dans le répertoire

Question

Comment puis-je spécifier Vim paramètres pour tous les fichiers dans le répertoire courant?

La solution idéale serait si Vim a cherché et lu .vimrc dans le répertoire courant avant de chercher ~/.vimrc, et d'appliquer les paramètres pour l'ensemble de l'arborescence.

J'ai vu un plugin, mais cela signifie que les paramètres appliqués ne sont pas transparents car ils nécessitent le plugin à installer. En revanche, une modeline est transparent depuis quel que soit l'utilisateur vimrc ou spécifiques vim invocation de la modeline paramètres seront appliqués pour ce fichier.

Choses que j'ai essayé sont

• placer une .vimrc dans le répertoire de travail
• :so vimrc dans le modeline.

Je suppose que les deux ne fonctionnent pas pour des raisons de sécurité. Je n'ai pas besoin de toute la puissance d'un vimrc; être lié à des paramètres acceptables par une modeline suffirait. Mon objectif est de rendre plus facile pour les vimmers à adopter des normes de codage dans un projet.

Answer 1

Vous pouvez mettre quelque chose comme cela dans la``

Answer 2

Je suggère fortement de ne pas utiliser``

Même avec , sous * nix, vim se déroulera encore autocommands, shell, et al., si vous possédez le fichier. Donc, si vous arrivé à éditer un fichier dans ce tarball je vous ai envoyé avec un contenant :

``

vous serez probablement moins amusé que je le ferai.

Answer 3

Je suis un adepte du plugin façon. Pour plusieurs raisons:

• Modelines sont particulièrement limitées: on ne peut pas définir les variables (que des airs d'autres (ft)de plugins, comme "si les accolades de l'extrait d'être sur un retour à la ligne ?"), ou de la fonction d'appel de leur part (je ne pas me limiter à des normes de codage, j'ai également réglé le makefile à utiliser en fonction du répertoire courant)
• SEC: avec modelines, un réglage doit être répété dans chaque fichier, si il y a trop de choses à régler ou de réglages, de changer, il va rapidement devenir difficile à maintenir, en outre, il nécessite l'utilisation d'un modèle-expander plugin (que vous devriez considérer si vous avez plusieurs vimmers dans votre projet).
• Ce n'est pas utilise vim pour se développer. Je ne veux pas être embêtée par les autres paramètres de l'éditeur, pourquoi devrais-je parasite les leurs?
• Il est plus facile de demander vimmers pour installer un même plugin, plutôt que de leur demander de copier-coller, et de maintenir, les mêmes lignes dans leur .vimrc
• Les paramètres peuvent être enregistrés avec les autres fichiers de projet (cvs/svn/git/whatever)
• Il est vraiment facile d'avoir un fichier de configuration par projet, avec le plugin, j'ai un fichier de configuration global pour les normes de codage de l'ensemble du projet, et des fichiers de configuration spécifiques pour chaque sous-projet (qui makefile à utiliser, qui exécutable à l'appel, ...)

BTW, sth de la solution peut être utilisée pour source un fichier de configuration unique. Ceci est très similaire à la plugin approche à l'exception de l' .vimrc doit être parasited avec les options globales, et il ne supporte pas facilement de plusieurs partagé des fichiers de configuration.

Answer 4

Placer une .vimrc dans le répertoire de travail est réellement pris en charge, seuls désactivé par défaut. Voir :h 'exrc' et :h startup pour plus de détails, paramètre 'exrc' permettra de lecture .vimrc à partir du répertoire courant.

Il est aussi recommandé d' :set secure lors de l'utilisation de ce. Cela verrouille :autocmd, shell et les commandes d'écriture pour .vimrc dans le répertoire courant.

Une autre chose qui pourrait être intéressant de regarder est la configuration d'une session (:h session) avec une vue standard et réglages du projet.

Tout cela étant dit, je serais probablement aller avec le plugin option détaillée par Luc hermitte (en) moi-même.

Answer 5

Pour minimiser les risques de sécurité avec TOUT "autorun" caractéristiques de RIEN, ces jours, je vous conseille d'utiliser vim de fonctionnalités existantes au lieu de plugins (portabilité des bagages)?

Par exemple.

Mon dossier local du vimrc fichier est nommé "_gvimrc" (sur le but). Cela réduit l'espoir pour des gens comme phen de amuser à nos dépens. :-)

Dans mon $VIM/.fichiers vimrc, j'ai inséré:

if filereadable("_gvimrc")
    source _gvimrc
endif

à la fin.

J'utilise "filereadable()" sur "fileexists()" comme plus tard a une certaine excentricité quand torturé avec l'ouverture de plusieurs (10+) de fichiers à la fois, (je ne sais pas pourquoi).

Bien sûr, vous pouvez donner votre propre nom de fichier unique pour obscurcir les potentiels fauteurs de troubles plus loin. Telles que "_mygvimrc", "_gobbledygook", etc. Vous avez juste besoin de s'installer sur un nom normalisé et de la source en conséquence dans votre $VIM/.vimrc. En s'appuyant sur vi/vim internes pour cela élimine les problèmes de portabilité. MAIS, NE PAS le nommer .vimrc (ou _vimrc) pour empêcher récursive de sourcing dans le cas où vous êtes à l'édition de l' $VIM/.vimrc fichier avec vim plus tard.

Été en utilisant ce depuis Windoze 98SE, par le biais de Windork XP Pro, et maintenant Windorkier 7 (5+ ans déjà). Je vais marquer une liste de .txt des fichiers dans l'Explorateur, puis utilisez la fonction "Éditer avec plusieurs Vim", résultant de multiples vim ouverture des fenêtres simultanément. Pour mon travail, je le fais plusieurs fois par jour, tous les jours. Tous les fichiers ont été traités avec ce que j'ai mis dans mon local _gvimrc.