Ubuntu Bionic vi/vim not working correctly

[Roel Van de Paar]

The vim default configuration in Bionic does not match Ubuntu 17.10 nor Centos 7 and is hard to use. It auto-inserts tabs or spaces, and the '/' search mode command works differently (pressing enter is required before you can use cursors left/right).

For some discussion, please see https://askubuntu.com/questions/1026820/vi-vim-usage-in-ubuntu-bionic-not-normal/1028684#1028684

Setting :set nocompatbile in ~/.vimrc fixes it, but this should not be required.

[Thiago Martins (martinx)]

Thanks! vim on Ubuntu 18.04 is so annoying! lol

The workaround is good!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[flashydave (dave-opensourcesolutions)]

The "set nocompatible" fix doesn't work on 18.04.1 LTS server. The trigger condition appears to be a random operation and not repeatable. Symptoms include loss of tab completion and syntax highlighting. It is persistent through a re-edit of the same file. The fault can be cleared by removing .viminfo until the next random occurence.

Given the use of vi on a server instance with no GUU is very high I would request the importance of this bug is set to high as it significantly damages productivity when used in a professional context.

[flashydave (dave-opensourcesolutions)]

The mis-interpretation of PC cursor keys when accessed vi ssh (as described in the discussion link above) is very remeniscent of trying to use vim.tiny not vim.basic (which server install defaults to). Maybe this along with my above post will help characterise the bug.

[flashydave (dave-opensourcesolutions)]

Further investigation with a recompiled version more recent than that shipped with 18.04 yields that syntax highlighting failure is caused by redrawtime being exceeded - often triggered after using G to move to the end of the file. It is not possible to set "syntax on" manually at that point as it immediatetly gets disabled again unless you move to the start of the file with g.

This explains the "persistence" due to the "jump to the previously edited line in the file" setting being set - but forgetting it upon deletion of .viminfo as this is where this Info is stored. Without it vi opens with the cursor at line 1.

In my case this problem has occurred following an upgrade and has never happened before on the same hardware running the same applications for many years with lots of files being edited multiple times every day - day in day out. Ie something in the timing dynamics when running vi has changed wirh 18.04

See https://github.com/vim/vim/issues/2790 for further discussion and possible workarounds.

[flashydave (dave-opensourcesolutions)]

Just by way of more info I was editing a gitolite conf file of 4096 lines with the following stats to render the syntax with the cursor at the end of the file
The total time taken was 5 seconds. By default redrawtime is set to 2 seconds so the 5 srconds taken represents a considetable drop off in performance. It is true that 18.04 feels sluggish. Maybe Spectre malware fix slowdowns?

TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN
  1.580522 4214 96 0.002875 0.000375 gitoliteRefex \(^\s*\(-\|R\|RW+\?C\?D\?\)\s\+\)\@<=\S.\{-}\(\s*=
  1.542289 4068 2712 0.006048 0.000379 gitoliteConfigKey \(\(config\|option\)\s\+\)\@<=[^ =]*
  0.986339 1426 0 0.032778 0.000692 gitoliteCreateRule \(^\s*C\s.*=\s*\)\@<=\S[^#]*[^# ]
  0.777079 4068 4068 0.000870 0.000191 gitoliteConfigVal \(=\s*\)\@<=\S.*
  0.652198 1502 95 0.040000 0.000434 gitoliteDenyRule \(^\s*-\s.*=\s*\)\@<=\S[^#]*[^# ]
  0.059132 2852 1426 0.000100 0.000021 gitoliteRule \(^\s*\)\@<=\(-\|C\|R\|RW+\?C\?D\?\)\s\@=
  0.033258 4118 1356 0.000049 0.000008 gitoliteConfigLine ^\s*\(config\|option\|include\|subconf\)\s[^#]*
  0.024610 4142 1426 0.000035 0.000006 gitoliteRuleLine ^\s*\(-\|C\|R\|RW+\?C\?D\?\)\s[^#]*
  0.016784 6026 3258 0.000013 0.000003 gitoliteGroup @\S\+
  0.014909 4142 1395 0.000013 0.000004 gitoliteRepoError ^\s*\S\+\s*=
  0.014868 4118 657 0.000045 0.000004 gitoliteRepoLine ^\s*repo\s\+[^=]*$
  0.013410 4118 0 0.000044 0.000003 gitoliteRepoError ^\s*repo.*=
  0.010654 4400 574 0.000045 0.000002 gitoliteComment #.*
  0.004946 4118 1 0.000014 0.000001 gitoliteGroupLine ^\s*@\S\+\s*=\s*\S.*$
  0.003386 4118 0 0.000009 0.000001 gitoliteTemplateLine ^=begin template-data$
  0.001547 4118 0 0.000002 0.000000 gitoliteSpecialRefex /USER/
  0.001208 4118 0 0.000001 0.000000 gitoliteSpecialRefex NAME/

  5.737139 65666

[flashydave (dave-opensourcesolutions)]

Setting regexpengine=1 drops this back down to 1.4 seconds. So either this is the root cause of this particular slowdown (i.e. when syntax highlighting gitolite format files) or at least compensates for whatever is the root cause. According to https://stackoverflow.com/posts/38521226 the default regexp engine changed with Vim 7.4. This was the version shipped with Trusty onwards so in theory was already in use on 14.04 and 16.04 ubuntu so something doesnt quite tie up

[Thiago Martins (martinx)]

Any news about this?!

The vim is still very bad on Ubuntu 20.04.

Any recommendation for a better /etc/vim/* ?