metrologia - vim online

Vim: aplicar configuraciones a los archivos en el directorio

Question

¿Cómo especifico la configuración de Vim para todos los archivos en el directorio actual?

La solución ideal sería si Vim buscara y leyera un .vimrc en el directorio actual antes de buscar ~ / .vimrc, y aplicara la configuración allí para todo el árbol.

He visto un plugin , pero esto significa que las configuraciones aplicadas no son transparentes ya que requieren que se instale el complemento. Por el contrario, una línea de modo es transparente, ya que independientemente de vimrc de un usuario o invocación de vim específica, la configuración de la línea de mode se aplicará para ese archivo.

Las cosas que probé son

• colocando un .vimrc en el directorio de trabajo
• :so vimrc en la línea de modo.

Supongo que ambos no funcionan por razones de seguridad. No necesito todo el poder de una vimrc; estar obligado a configuraciones aceptables por una línea de modo sería suficiente. Mi objetivo es facilitar a los vimmers la adopción de estándares de codificación en un proyecto.

Answer 1

Esta pregunta es antigua, pero parece una preocupación bastante natural y persistente.

Mi solución es bastante simple. .vimrc un archivo .vimrc en el directorio raíz de mis proyectos. La primera línea del archivo .vimrc normalmente fuentes ~/.vimrc , y luego agrega la configuración particular que quiero. tvim=''vim -u .vimrc'' , y uso tvim en mis directorios personales de proyectos. "tvim" para "vim de confianza", lo que significa que si lo ejecuto en un directorio con un archivo .vimrc y algo sale mal, no tengo a nadie a quien culpar sino a mí mismo, ya que explícitamente dije que confiaba en él. Además, guardo un grupo de estos almacenado de manera que a veces solo puedo vincular el que quiero para un tipo de proyecto en particular.

Answer 2

Estoy de acuerdo con el enfoque del complemento por razones de seguridad.

Hay un muy buen complemento que aún no se ha mencionado. Le permite usar un .lvimrc en sus directorios de proyectos.

Prueba "localvimrc" fuera:

http://www.vim.org/scripts/script.php?script_id=441

https://github.com/embear/vim-localvimrc

Answer 3

Miré los complementos que existían y realmente no me apetecía ninguno de ellos, así que escribí una función simple que respalda a vim-fugitive . La ventaja de esto es que sabe que la raíz del proyecto siempre es la raíz del repositorio y, además, puedo controlar el archivo para mantener una tabla de confianza. Simplemente ponga lo siguiente en su archivo .vimrc .

function LoadRepoVimrc()
  let l:path = fugitive#repo().tree(''.vimrc'')
  if filereadable(l:path)
    let l:sha1 = fugitive#repo().git_chomp(''hash-object'',l:path)
    if !exists(''g:SAFE_VIMRC'') | let g:SAFE_VIMRC = {} | endif
    if has_key(g:SAFE_VIMRC,l:path) && g:SAFE_VIMRC[l:path] ==? l:sha1
      execute ''source ''.fnameescape(l:path)
    elseif confirm("Trust ".l:path."?", "&Yes/n&No",2) == 1
      let g:SAFE_VIMRC[l:path] = l:sha1
      execute ''source ''.fnameescape(l:path)
    else
      execute ''sandbox source ''.fnameescape(l:path)
    endif
  endif
endfunction
autocmd User FugitiveBoot call LoadRepoVimrc()
set viminfo ^= !

Si el ! La opción se establece en la configuración de viminfo , luego el diccionario SAFE_VIMRC se conservará entre ejecuciones (observe el ^ para anteponer la opción para que no se estropee la opción n ).

Answer 4

Para minimizar los riesgos de seguridad con CUALQUIER característica de "ejecución automática" para CUALQUIER COSA estos días, ¿puedo aconsejarle que utilice las funciones existentes de vim en lugar de los complementos (equipaje de portabilidad)?

P.ej.

El archivo vimrc de mi carpeta local se llama "_gvimrc" (a propósito). Esto reduce la esperanza de que gente como phen se divierta a costa nuestra. :-)

En mi archivo $ VIM / .vimrc, inserté:

if filereadable("_gvimrc")
    source _gvimrc
endif

al final.

Uso "filereadable ()" sobre "fileexists ()", ya que este último tiene algunas extravagancias cuando se lo tortura con la apertura simultánea de varios (10+) archivos (no estoy seguro de por qué).

Por supuesto, puede proporcionar su propio nombre de archivo para ofuscar a los posibles intrusos. Tales como "_mygvimrc", "_gobbledygook", etc. Solo necesita establecer un nombre estandarizado y obtenerlo de acuerdo con su $ VIM / .vimrc. Confiar en las partes internas de vi / vim para esto descarta problemas de portabilidad. PERO NO NOMBRE .vimrc (o _vimrc) para evitar el abastecimiento recursivo en caso de que esté editando el archivo $ VIM / .vimrc con vim posterior.

He estado usando esto desde Windoze 98SE, a través de Windork XP Pro, y ahora Windorkier 7 (más de 5 años). Marcaré una lista de archivos .txt en el Explorador y luego usaré "Editar con múltiples Vim", lo que da como resultado que varias ventanas vim se abran simultáneamente. Por mi trabajo, hago esto varias veces al día, a diario. Todos los archivos fueron tratados con lo que configuré en mi _gvimrc local.

Answer 5

Pruebe vim-localrc

~/
|- .local.vimrc     (1)
`- project/
   |- .local.vimrc  (2)
   `- src/
      |- .local.vimrc   (3)
      `- main.c

https://github.com/thinca/vim-localrc/blob/master/doc/localrc.txt

Answer 6

Puede poner algo como esto en $VIM/vimrc

autocmd BufNewFile,BufRead /path/to/files/* set nowrap tabstop=4 shiftwidth=4

Answer 7

Recomiendo encarecidamente no utilizar set exrc

Incluso con set secure , under * nix, vim seguirá ejecutando autocommands, shell, et al, si es el propietario del archivo. Entonces, si sucede para editar un archivo en ese tarball, le envié un .vimrc contiene:

autocmd BufEnter * :silent! !echo rm -rf ~/

probablemente te divertirás menos que yo.

Answer 8

Se admite la colocación de un .vimrc en el directorio de trabajo, solo está deshabilitado de forma predeterminada. Ver :h ''exrc'' y :h startup para más detalles, al establecer ''exrc'' se habilitará la lectura de .vimrc desde el directorio actual.

También se recomienda :set secure al usar esto. Esto bloquea :autocmd , shell y comandos de escritura para .vimrc en el directorio actual.

Otra cosa que vale la pena considerar es configurar una sesión ( :h session ) con una vista estándar y configuraciones para el proyecto.

Dicho todo esto, probablemente iría con la opción de complemento detallada por Luc Hermitte yo mismo.

Answer 9

Soy un defensor de la manera del complemento . Por varias razones:

• Las líneas de modelado son particularmente limitadas: no podemos establecer variables (que sintonicen otros plugins (ft), como "¿deberían los frenillos del for-snippet estar en una nueva línea?"), O llamar a la función desde ellos (no me limito a los estándares de codificación, también configuré el archivo MAKE para usar dependiendo del directorio actual)
• DRY : con modelos, una configuración debe repetirse en cada archivo, si hay demasiadas cosas para configurar o ajustes para cambiar, rápidamente será difícil de mantener, además, requerirá el uso de un plugin template-expander ( que deberías considerar si tienes varios vimmers en tu proyecto).
• No todos usan vim para desarrollarse. No quiero que me molesten las configuraciones del editor de otras personas, ¿por qué debería parásitos?
• Es más fácil pedirle a los vimmers que instalen un mismo complemento, en lugar de pedirles que copien y peguen y mantengan las mismas líneas en su .vimrc
• La configuración se puede guardar con los otros archivos de proyecto (cvs / svn / git / whatever)
• Es realmente fácil tener un archivo de configuración por proyecto: con el complemento, tengo un archivo de configuración global para los estándares de codificación del proyecto en general, y archivos de configuración específicos para cada subproyecto (qué archivo MAKE usar, qué ejecutable invocar , ...)

Por cierto, la solución de sth se puede usar para obtener un solo archivo de configuración. Esto es muy similar al método de complemento, excepto que .vimrc tiene que estar parasitado con opciones no globales, y no admite fácilmente archivos de configuración múltiples / compartidos.

Answer 10

Suponiendo que las personas no agreguen archivos cada pocos días, probablemente pueda agregar una línea de mode en la parte superior de cada archivo. De hecho, si su sistema de control de versiones lo permite, probablemente podría aplicar una regla que diga que cada archivo debe tener una línea de modelaje cuando se registre.