FS#55641 - [cmake] vim files override behaviour of vim-runtime

Attached to Project: Arch Linux
Opened by Maarten de Vries (de-vri-es) - Friday, 15 September 2017, 18:43 GMT
Last edited by Eli Schwartz (eschwartz) - Friday, 15 September 2017, 20:26 GMT
Task Type General Gripe
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Both cmake-3.9.2-2 and vim-runtime-8.0.1092-1 include syntax highlighting and an indent plugin for cmake:

$ pacman -Qo $(find /usr/share/vim -name 'cmake.vim')
/usr/share/vim/vimfiles/syntax/cmake.vim is owned by cmake 3.9.2-2
/usr/share/vim/vimfiles/indent/cmake.vim is owned by cmake 3.9.2-2
/usr/share/vim/vim80/syntax/cmake.vim is owned by vim-runtime 8.0.1092-1
/usr/share/vim/vim80/indent/cmake.vim is owned by vim-runtime 8.0.1092-1

The files installed by the cmake package seem to override the settings from the vim-runtime files. Either that or both versions are used.

The cmake version contains an unconditional `setlocal et` which I find very annoying. It seems to me there is no reason to use the cmake provided files over the vim-runtime files. The default installation procedure of cmake doesn't even install them in /usr/share/vim. That is done manually in the PKGBUILD:

vimpath="${pkgdir}/usr/share/vim/vimfiles"
install -d "${vimpath}"/{help,indent,syntax}
ln -s /usr/share/cmake-${pkgver%.*}/editors/vim/indent/cmake.vim \
"${vimpath}"/indent/
ln -s /usr/share/cmake-${pkgver%.*}/editors/vim/syntax/cmake.vim \
"${vimpath}"/syntax/

Could those symlinks be dropped from the PKGBUILD?
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Friday, 15 September 2017, 20:26 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Overriding vim-runtime is not a sin, it is the *policy* of Arch Devs/TUs.
Comment by Eli Schwartz (eschwartz) - Friday, 15 September 2017, 19:17 GMT
I would assume the reason for providing those files in vim's override directory (/usr/share/vim/vimfiles/) is to, well, override the vim.org ones with the cmake.org ones. In other words, this is literally doing exactly what it was meant to do.

If you disagree with the philosophy behind cmake.org's decision that cmake files "should" use expandtab, I suggest you take it up with the cmake developers and try to convince them. Meanwhile, I think /usr/share/vim/vim80/indent/cmake.vim should probably be fixed to conform with the cmake developers' expectations, not that it matters a lot since we install the updated files anyway.
Comment by Maarten de Vries (de-vri-es) - Friday, 15 September 2017, 19:45 GMT
The files provided by cmake are not installed in a directory where they are used by vim. That is done by the PKGBUILD. To me that looks like cmake provides the file as a suggestion for the user, not as something to be activated automatically system wide.

To me upstream vim is more authoritative on the default vim settings than cmake is. When I install cmake I expect to get the command line tools and files related to that. I don't expect the configuration of my editor to change :/
Comment by Eli Schwartz (eschwartz) - Friday, 15 September 2017, 20:25 GMT
But that's really not true, vim can be somewhat conservative about updating runtime files. (colorschemes are dead, for example, even when they're buggy.)
And when they get updated, it is only because someone who cares pursues the point. Case in point, the cmake.org files have a number of updates that supersede the vim.org ones, and no one updated the "authoritative" version similarly.

But it seems this has become less about the cmake.org files being inferior and more about your expectation that vim.org files shall be considered authoritative and not to be overridden. Which is contraindicated by a number of official repository packages; take a look at the output of `pkgfile -vg '/usr/share/vim/vimfiles/*/*.vim'` and compare it to the vim80 files.

Loading...