Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#14647 - vi, vim, gvim PKGBUILDs set incorrect global-runtime directory
Attached to Project:
Arch Linux
Opened by craig (craig) - Saturday, 09 May 2009, 17:38 GMT
Last edited by Eric Belanger (Snowman) - Sunday, 10 May 2009, 03:33 GMT
Opened by craig (craig) - Saturday, 09 May 2009, 17:38 GMT
Last edited by Eric Belanger (Snowman) - Sunday, 10 May 2009, 03:33 GMT
|
DetailsDescription:
Per vim help, the default runtimepath for vim is: Unix: "$HOME/.vim, $VIM/vimfiles, $VIMRUNTIME, $VIM/vimfiles/after, $HOME/.vim/after" A ./configure flag in the build() sections of the vi, vim, and gvim PKGBUILDS specifies: --with-global-runtime=/usr/share/vim which results in a runtimepath of: ~/.vim,/usr/share/vim,/usr/share/vim,/usr/share/vim/after,~/.vim/after Aside from being slightly redundant, add-on vim packages (correctly) installed to /usr/share/vim/vimfiles are not properly seen by vim. (e.g. in my current case: latex-suite from AUR) Changing the PKGBUILD to instead read: --with-global-runtime=/usr/share/vim/vimfiles results in a correct runtime path of: ~/.vim,/usr/share/vim/vimfiles,/usr/share/vim,/usr/share/vim/vimfiles/after,~/.vim/after Additional info: * package version(s) 7.2.65-1 Steps to reproduce: From within vi, vim, gvim enter the following to see the current runtimepath: :set runtimepath |
This task depends upon
Closed by Eric Belanger (Snowman)
Sunday, 10 May 2009, 03:33 GMT
Reason for closing: Fixed
Additional comments about closing: 2009-05-09: A task closure has been requested. Reason for request: It looks like the packages added to testing yesterday have ditched the with-global-runtime setting, so when these become available, I assume the problem will disappear. My bad for not re-looking for last-minute fixes...
Sunday, 10 May 2009, 03:33 GMT
Reason for closing: Fixed
Additional comments about closing: 2009-05-09: A task closure has been requested. Reason for request: It looks like the packages added to testing yesterday have ditched the with-global-runtime setting, so when these become available, I assume the problem will disappear. My bad for not re-looking for last-minute fixes...