Consejo para agregar `set nocompatible` como primera línea de .vimrc

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:

set nocompatible " Use VIM settings rather than Vi settings; this *must* be
                 " first in .vimrc 

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 un set nocompatible explícito set 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.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım