[arch-general] Where should system-wide vim files go?
I installed vim-peaksea from the AUR the other day and couldn't use it, because it installed in /usr/share/vim/colors/peaksea.vim. This seems a fairly standard directory, but its not in runtimepath on a fresh install (AFAIK). Checked out some other vim colour-themes on the AUR, the majority seem to install to the same location. Some choose /usr/share/vim/vim** instead, but that breaks when vim updates. Perhaps /usr/share/vim/vimfiles makes more sense (only found one PKGBUILD using that so far). So what's the 'correct' behaviour? The vim split package doesn't seem to do any patches affecting runtimepath, so probably I assume runtimepath is an upstream default. In that case, should AUR packages correct their location? Posting to arch-general because it overlaps and isn't solely an AUR issue.
Hi, On Mon, 04 Apr 2011, Oon-Ee Ng wrote:
Checked out some other vim colour-themes on the AUR, the majority seem to install to the same location. Some choose /usr/share/vim/vim** instead, but that breaks when vim updates. Perhaps /usr/share/vim/vimfiles makes more sense (only found one PKGBUILD using that so far).
I believe that now the correct behaviour is for things that are version specific to go in /usr/share/vim/vimXX and everything else to go in /usr/share/vim/vimfiles. Some vim-ninja can probably correct me, though :-) Pete. PS. Yes, by this standard, many PKGBUILDS in the AUR are wrong, and need fixing.
On Tue, Apr 5, 2011 at 10:47, Peter Lewis <plewis@aur.archlinux.org> wrote:
Hi,
On Mon, 04 Apr 2011, Oon-Ee Ng wrote:
Checked out some other vim colour-themes on the AUR, the majority seem to install to the same location. Some choose /usr/share/vim/vim** instead, but that breaks when vim updates. Perhaps /usr/share/vim/vimfiles makes more sense (only found one PKGBUILD using that so far).
I believe that now the correct behaviour is for things that are version specific to go in /usr/share/vim/vimXX and everything else to go in /usr/share/vim/vimfiles.
Some vim-ninja can probably correct me, though :-)
Pete.
PS. Yes, by this standard, many PKGBUILDS in the AUR are wrong, and need fixing.
IMNSHO there are *very* few vim extensions that should ever be installed centrally. I'd recommend every vim user to embrace GetLatestVimScripts[1] instead. For the other stuff (read "broken vim extensions") I created vim-scripts-mgr[2]. :-) /M [1]: http://www.vim.org/scripts/script.php?script_id=642 [2]: http://aur.archlinux.org/packages.php?ID=26318 -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On Tue, Apr 5, 2011 at 13:18, Magnus Therning <magnus@therning.org> wrote:
IMNSHO there are *very* few vim extensions that should ever be installed centrally. I'd recommend every vim user to embrace GetLatestVimScripts[1] instead. For the other stuff (read "broken vim extensions") I created vim-scripts-mgr[2]. :-)
I'm interested in the cons of having centrally installed vim plugins. For me it seems these things you mentioned are basically doing a job of a package manager (keeping track of, and updating files) so why not use pacman for this purpose? -- János
2011/4/5 János Illés <ijanos@gmail.com>:
On Tue, Apr 5, 2011 at 13:18, Magnus Therning <magnus@therning.org> wrote:
IMNSHO there are *very* few vim extensions that should ever be installed centrally. I'd recommend every vim user to embrace GetLatestVimScripts[1] instead. For the other stuff (read "broken vim extensions") I created vim-scripts-mgr[2]. :-)
I'm interested in the cons of having centrally installed vim plugins. For me it seems these things you mentioned are basically doing a job of a package manager (keeping track of, and updating files) so why not use pacman for this purpose?
Because the vast majority of vim extensions I've come across are turned on as soon as they are installed, which means that installing them centrally turns them on for *all* users on the system. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On Wed, Apr 6, 2011 at 4:41 PM, Magnus Therning <magnus@therning.org> wrote:
2011/4/5 János Illés <ijanos@gmail.com>:
On Tue, Apr 5, 2011 at 13:18, Magnus Therning <magnus@therning.org> wrote:
IMNSHO there are *very* few vim extensions that should ever be installed centrally. I'd recommend every vim user to embrace GetLatestVimScripts[1] instead. For the other stuff (read "broken vim extensions") I created vim-scripts-mgr[2]. :-)
I'm interested in the cons of having centrally installed vim plugins. For me it seems these things you mentioned are basically doing a job of a package manager (keeping track of, and updating files) so why not use pacman for this purpose?
Because the vast majority of vim extensions I've come across are turned on as soon as they are installed, which means that installing them centrally turns them on for *all* users on the system.
/M
Which (for some of us at least) would be the point. Most extensions that I use don't actually do anything outside their specific purview, so having many installed doesn't necessarily affect anything. In the case of colourschemes, having them installed system-wide means everyone can use them, which is good, isn't it? Rather than each person having to copy/install them individually.
On Wed, Apr 6, 2011 at 10:04, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Wed, Apr 6, 2011 at 4:41 PM, Magnus Therning <magnus@therning.org> wrote:
2011/4/5 János Illés <ijanos@gmail.com>:
On Tue, Apr 5, 2011 at 13:18, Magnus Therning <magnus@therning.org> wrote:
IMNSHO there are *very* few vim extensions that should ever be installed centrally. I'd recommend every vim user to embrace GetLatestVimScripts[1] instead. For the other stuff (read "broken vim extensions") I created vim-scripts-mgr[2]. :-)
I'm interested in the cons of having centrally installed vim plugins. For me it seems these things you mentioned are basically doing a job of a package manager (keeping track of, and updating files) so why not use pacman for this purpose?
Because the vast majority of vim extensions I've come across are turned on as soon as they are installed, which means that installing them centrally turns them on for *all* users on the system.
/M
Which (for some of us at least) would be the point. Most extensions that I use don't actually do anything outside their specific purview, so having many installed doesn't necessarily affect anything. In the case of colourschemes, having them installed system-wide means everyone can use them, which is good, isn't it? Rather than each person having to copy/install them individually.
Indeed, there are arguably some exceptions, but I continue to argue that the majority of vim extensions should be installed on a per-user basis. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On Wed, Apr 6, 2011 at 4:41 AM, Magnus Therning <magnus@therning.org> wrote:
Because the vast majority of vim extensions I've come across are turned on as soon as they are installed, which means that installing them centrally turns them on for *all* users on the system.
You could do set noloadplugins and then use runtime! to load only the ones you like. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
On Mon, Apr 4, 2011 at 9:01 PM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
I installed vim-peaksea from the AUR the other day and couldn't use it, because it installed in /usr/share/vim/colors/peaksea.vim. This seems a fairly standard directory, but its not in runtimepath on a fresh install (AFAIK).
Checked out some other vim colour-themes on the AUR, the majority seem to install to the same location. Some choose /usr/share/vim/vim** instead, but that breaks when vim updates. Perhaps /usr/share/vim/vimfiles makes more sense (only found one PKGBUILD using that so far).
So what's the 'correct' behaviour? The vim split package doesn't seem to do any patches affecting runtimepath, so probably I assume runtimepath is an upstream default. In that case, should AUR packages correct their location?
Posting to arch-general because it overlaps and isn't solely an AUR issue.
plugins installed into $VIM/vimfiles works. i thought that's the correct place for plugins. /usr/share/vim/vimXX directory should only be used by vim packages that updates along with vim. that's my understanding of the vim directories.
On Wed, Apr 6, 2011 at 5:33 PM, Auguste Pop <auguste@gmail.com> wrote:
On Mon, Apr 4, 2011 at 9:01 PM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
I installed vim-peaksea from the AUR the other day and couldn't use it, because it installed in /usr/share/vim/colors/peaksea.vim. This seems a fairly standard directory, but its not in runtimepath on a fresh install (AFAIK).
Checked out some other vim colour-themes on the AUR, the majority seem to install to the same location. Some choose /usr/share/vim/vim** instead, but that breaks when vim updates. Perhaps /usr/share/vim/vimfiles makes more sense (only found one PKGBUILD using that so far).
So what's the 'correct' behaviour? The vim split package doesn't seem to do any patches affecting runtimepath, so probably I assume runtimepath is an upstream default. In that case, should AUR packages correct their location?
Posting to arch-general because it overlaps and isn't solely an AUR issue.
plugins installed into $VIM/vimfiles works. i thought that's the correct place for plugins. /usr/share/vim/vimXX directory should only be used by vim packages that updates along with vim. that's my understanding of the vim directories.
I guess I'll go bug some AUR packages now, most of them just install in $VIM (which isn't sourced by default where $VIM/vimfiles is in Arch packages).
participants (6)
-
Auguste Pop
-
János Illés
-
Kaiting Chen
-
Magnus Therning
-
Oon-Ee Ng
-
Peter Lewis