Rely on ‘runtimeparh’ in import autoload

[Matan Nassau]

Hello.

When is it good practice to use the import autoload form that relies on ‘runtimepath’?

import autoload ‘foo.vim’

I think plugins generally know where their autoload stuff is, and can gain a few milliseconds by pointing the import directly at it with a relative path.

And, the runtimepath form generally won't work when ‘loadplugins’ isn’t set (when starting Vim with --clean for example).

So what is the feature for, when is it a good time to use it?


Matan

[Lifepillar]

On 2023-11-24, Matan Nassau <matan....@gmail.com> wrote:
> When is it good practice to use the import autoload form that relies
> on ‘runtimepath’?
>
> import autoload ‘foo.vim’
>
> I think plugins generally know where their autoload stuff is, and can
> gain a few milliseconds by pointing the import directly at it with
> a relative path.
>
> And, the runtimepath form generally won't work when ‘loadplugins’
> isn’t set (when starting Vim with --clean for example).

What is the use case for an autoload mechanism when plugins have been
turned off? Are you talking about `import autoload` statements in
a vimrc file?

> So what is the feature for

Vim 9 script inherits the autoload mechanism from Vim legacy script,
where runtimepath is used. I think that is the main reason for that
behaviour.

>, when is it a good time to use it?

It's just a matter of personal preference. In most cases the difference
won't be noticeable. I'd stick with relative paths to avoid potential,
although probably rare, name conflicts.

Life.

[Tony Mechelynck]

The advantage of using 'runtimepath' (not 'runtimeparh') is that the
sysadmin and the user can to some extent customize the plugin by
adding their own scripts in other directories than those located under
$VIMRUNTIME (which is reserved for scripts distributed together with
Vim). For instance, if a sysadmin loads a set of scripts for all users
of a given system under $VIM/vimfiles/… a user who knows what (s)he's
doing can customize it by means of additional scripts of the same name
and path below (on Unix) $HOME/.vim/after/… or (on Windows but in Vim
notation) $HOME/vimfiles/after/…

Also, if a third-party plugin (installed under $VIM/vimfiles/… or
$HOME/.vim/… etc.) becomes an "official plugin" distributed with Vim
(as happened in the past for matchit, netrw, VimBall, and others), its
scripts will change location and come under $VIMRUNTIME/… By using
'runtimepath' the plugin will continue functioning in exactly the same
way regardless of under which of the 'runtimepath' directories its
scripts are installed.

Best regards,
Tony.

[Matan Nassau]

> On Nov 25, 2023, at 08:20, Lifepillar <lifep...@lifepillar.me> wrote:
>
> What is the use case for an autoload mechanism when plugins have been
> turned off? Are you talking about `import autoload` statements in
> a vimrc file?

I have a makefile that tests Vim plugins, each test in a dedicated vim --clean. I don’t need autoload per se here, I can explicitly source the autoload scripts, but a plugin script would fail if its import fails. So a plugin’s import autoload has to work even if the plugin isn’t loaded at Vim startup.

>> , when is it a good time to use it?
>
> It's just a matter of personal preference. In most cases the difference
> won't be noticeable. I'd stick with relative paths to avoid potential,
> although probably rare, name conflicts.

Thank you, that helps.


Matan