Pregunta:
Recuerdo (quizás a principios de la década de 2000) haber set nocompatible
como la primera línea de mi vimrc y la mayoría de las guías y tutoriales de Vim que recomiendan esa práctica.
Algunos ejemplos que podría encontrar fácilmente en línea:
-
vimrc
archivovimrc
de Alex Quinn comienza con:
set nocompatible " Use VIM settings rather than Vi settings; this *must* be
" first in .vimrc
- Cómo impulsé mi artículo de blog de Vim :
Antes de hacer cualquier otra cosa, asegúrese de tener la siguiente línea en su archivo .vimrc:
"Esto debe ser el primero, porque cambia otras opciones como efecto secundario establecer no compatible
Sin embargo, ese consejo no parece tener mucho sentido en estos días, ya que nocompatible
se usa automáticamente cada vez que se encuentra un archivo .vimrc de usuario , por lo que no parece haber ninguna razón convincente para usar set nocompatible
en su archivo .vimrc de usuario .
¿Cuándo fue necesaria esta práctica? ¿Se cambió el valor predeterminado a nocompatible cuando se encuentra el usuario vimrc en una versión específica de Vim, de modo que la configuración de nocompatible
era necesaria en versiones anteriores de Vim? ¿Existe alguna ventaja o efecto secundario de un set nocompatible
explícito no set nocompatible
que quizás me esté perdiendo?
Mientras investigaba este tema, encontré:
- Las referencias a esto son necesarias si desea utilizarlo como un sistema vimrc. Pero ese no parece ser el caso en la mayoría de los lugares, ya que los enlaces anteriores claramente hablan sobre el archivo .vimrc del usuario.
- Menciones de una distribución de Linux específica (Debian) que incluye explícitamente un
set compatible
en el archivo vimrc del sistema, que requeriría unset nocompatible
explícitoset nocompatible
para contrarrestar los valores predeterminados de la distribución. (No estoy seguro si eso tiene sentido.)
¿Hay algo de verdad o méritos en estos puntos anteriores? ¿O no fue set nocompatible
con el set nocompatible
de gran parte de la carga?
Respuesta:
¿Existe alguna ventaja o efecto secundario de un conjunto explícito no compatible que quizás me esté perdiendo?
De hecho, existen muchos efectos secundarios. Cada vez compatible
se activa o desactiva Vim volverá a analizar todas las opciones (excepto "terminal") y cambia los valores predeterminados cuando sea necesario. Después de eso, reconstruye bastantes tablas internas para iskeyword
, ortografía, vartabs
, etc. (ver didset_options()
y did_setoptions2()
en src/option.c
).
Así que bare set nocompatible
en el usuario vimrc es bastante indeseable (aunque la diferencia podría ser insignificante hoy en día) y, si no se elimina por completo, probablemente debería $VIMRUNTIME/defaults.vim
con if &compatible / endif
como en $VIMRUNTIME/defaults.vim
.
¿Cuándo fue necesaria esta práctica? ¿Se cambió el valor predeterminado a nocompatible cuando se encuentra el usuario vimrc en una versión específica de Vim, de modo que la configuración de nocompatible era necesaria en versiones anteriores de Vim?
Encontré el código para cambiar a nocompatible
en v5.0 pero no en v4.6. Así que supongo que está aquí a partir de Vim5 (principios de 1998).
También tenga en cuenta que &compatible
también podría establecerse explícitamente en la línea de comandos (como vim -C
), pero dudo que tenga sentido luchar contra la voluntad del usuario dentro de su propio vimrc. Quizás simplemente finish
entonces.