[Git-commits] [grml/grml-etc-core] 31dc67: vimrc: Major rework of the Grml configuration

Michael Prokop noreply at github.com
Wed May 20 16:32:07 CEST 2020


  Branch: refs/heads/master
  Home:   https://github.com/grml/grml-etc-core
  Commit: 31dc671f573000a4e83b715c2f1e52829d604e1c
      https://github.com/grml/grml-etc-core/commit/31dc671f573000a4e83b715c2f1e52829d604e1c
  Author: Darshaka Pathirana <dpat at syn-net.org>
  Date:   2020-05-20 (Wed, 20 May 2020)

  Changed paths:
    M etc/vim/vimrc

  Log Message:
  -----------
  vimrc: Major rework of the Grml configuration

A lot of vimrc configuration options are Grml defaults since the very start of
the project. It is time to clean up as much as possible.

The configuration file (now) clones most of the settings taken from the
defaults.vim file which usually is only loaded if no user vimrc file is found
(see: :help defaults.vim).

The custom Grml configuration was reviewed, fixed and reformatted. The
configuration file should now be more readable and better maintainable.

Include defaults.vim into our Grml configuration:

  We want to take over most of the configuration options defined in
  $VIMRUNTIME/defaults.vim (which is loaded instead the user vimrc file
  (only) if it does not exist / is not found).
  To prevent Vim from loading the defaults.vim again (in case the user
  vimrc file does not exists) we have to set `let g:skip_defaults_vim=1`.

  So we include everything of defaults.vim in our configuration and
  override only single options we do not want. (Currently only `set mouse=`).

  JFTR, in another step we could just source the defaults.vim file and
  override the settings we want to override.

  The background discussion can be found here: https://github.com/grml/grml-etc-core/commit/8cdc0df085211200682699b53e600fcccfe73989

Review and update Grml configuration options. Describe what they do and
why we set them:

'viminfo':

  * Vim default is: `'100,<50,s10,h`
  * `%` means: "When included, save and restore the buffer list. [...] Without
    a number all buffers are stored."
    (Not default, but used to be in our Grml configuration.)
  * `'100` means: "Maximum number of previously edited files for which the
    marks are remembered.
    (Default is `'100`, we should not decrease it to `'50` without reason.)
  * `<100` replaced `\"100`: "Old name of the '<' item, with the disadvantage
    that you need to put a backslash before the ", otherwise it will be recognized
    as the start of a comment!". Means: "Maximum number of lines saved for each
    register."
    (Default is `<50`.)
  * `:100` removed because it shortens the command-line history to 100
    (Default is taken from the option 'history' which defaults to 200 via `defaults.vim`.)
  * `n~/.viminfo` removed because the default name of the viminfo file is
    `"$HOME/.viminfo"` for Unix and OS/2 anyway.
  * `s10` is in Vim default: "Maximum size of an item in Kbyte.  If zero then
    registers are not saved.  Currently only applies to registers.
    (I would not remove the default without a reason.)
  * `h` is Vim default: "Disable the effect of 'hlsearch' when loading the
    viminfo file. When not included, it depends on whether ":nohlsearch" has been
    used since the last search command.
    (Not sure about this option, but I also tend to keep the Vim default.)
  * Source: https://github.com/grml/grml-etc-core/commit/8cdc0df085211200682699b53e600fcccfe73989#r38258350

'linebreak', 'ignorecase':

  * Long lines are not wrapped in the middle of a word.
  * Case is ignored in search patterns.
  * Both seem like good Grml options
  * Source: https://github.com/grml/grml-etc-core/commit/8cdc0df085211200682699b53e600fcccfe73989#r38257095

'comments':

  * Defines how comment lines look like
  * Removed the option because we want to keep the Vim default which includes
    everything the Grml configuration used to have (except for `n:` which made no sense)
  * https://github.com/grml/grml-etc-core/commit/8cdc0df085211200682699b53e600fcccfe73989#r38257448

'dictionary':

  * Used to lookup words for keyword completion with CTRL-X CTRL-K
  * The file '/usr/share/dict/word' does not exist (anymore) so the
    keyword completion was broken.

  | % dpkg -S /usr/share/dict/words
  | diversion by dictionaries-common from: /usr/share/dict/words
  | diversion by dictionaries-common to: /usr/share/dict/words.pre-dictionaries-common
  | wamerican: /usr/share/dict/words

'suffixes':

  * Files with the given suffixes get a lower priority when doing tab completion for file names
  * Vim default is: `.bak,~,.o,.h,.info,.swp,.obj`
  * `.h,.obj` were missing, readded them and changed the order
  * Discussion: https://github.com/grml/grml-etc-core/commit/8cdc0df085211200682699b53e600fcccfe73989#r38258537

'background':

  tl;dr: Removing 'set background=dark' is still a bit controversial
  because it used to "work" and assuming that the user has a dark
  background feels wrong. This setting should go to the personal
  `$HOME/.vimrc[.local]` file.

  Anyway, but it seems like that the Vim background detection
  _sometimes_ does not work so well. *sigh*

  (Vim in the Grml terminal seems to detect the dark background correctly.)

  Quoting the documentation:

  | Vim tries to set the default value according to the terminal used.
  | This will not always be correct.
  | [...]
  | When setting 'background' to the default value with:
  |         :set background&
  | Vim will guess the value.  In the GUI this should work correctly,
  | in other cases Vim might not be able to guess the right value.
  |
  | When the t_RB option is set, Vim will use it to request the background
  | color from the terminal.  If the returned RGB value is dark/light and
  | 'background' is not dark/light, 'background' will be set and the
  | screen is redrawn.  This may have side effects, make t_BG empty in
  | your .vimrc if you suspect this problem.  The response to t_RB can
  | be found in v:termrbgresp.
  | [...]
  | For MS-DOS, Windows and OS/2 the default is "dark".
  | For other systems "dark" is used when 'term' is "linux",
  | "screen.linux", "cygwin" or "putty", or $COLORFGBG suggests a dark
  | background.  Otherwise the default is "light".

  And this it what I observed
  (the current state of the background setting can be queried with ":set background?"):

  * Vim background detection in a **plain** terminal (gnome-terminal) in black-on-white and white-on-black **works**:

    % echo $TERM
    xterm-256color

  * Vim background detection in tmux in a terminal (gnome-terminal) in black-on-white does **not** seem to work:

    % echo $TERM
    screen-256color

  * Vim background detection in GNU/screen in a terminal (gnome-terminal) in black-on-white does **not** seem to work:

    % echo $TERM
    screen.xterm-256color

  Vim was started like this to test the configuration: `vim -c $THIS_VIMRC` (this skips most of the initializations).

  * Discussion: https://github.com/grml/grml-etc-core/commit/8cdc0df085211200682699b53e600fcccfe73989#r38258772

'BufReadPost':

  * When editing a file, always jump to the last known cursor position.
  * This setting was defined twice, decided to keep the default which taken over from defaults.vim
  * Discussion: https://github.com/grml/grml-etc-core/commit/8cdc0df085211200682699b53e600fcccfe73989#r38263223

'mouse':

  * We prefer to disable the mouse usage and use what we're used from older Vim versions.
  * Already defined in this file (overrides the default from defaults.vim)

Put autocommands around the has("autocmd")-block and avoid short name ('au').

And finally make the user aware that using the `$HOME/.vimrc.local` file
might not have the expected result.

Thanks: Michael Prokop (@mika) for the initial work


  Commit: a449b45c07709daf14a1f0f1678dd4acf06e91bc
      https://github.com/grml/grml-etc-core/commit/a449b45c07709daf14a1f0f1678dd4acf06e91bc
  Author: Michael Prokop <mika at grml.org>
  Date:   2020-05-20 (Wed, 20 May 2020)

  Changed paths:
    M etc/vim/vimrc

  Log Message:
  -----------
  Merge remote-tracking branch 'origin/github/pr/92'


Compare: https://github.com/grml/grml-etc-core/compare/1ebc9330553d...a449b45c0770


More information about the Git-commits mailing list