[vim/vim] Request for Vim9: Allow `:import autoload` to import files by relative paths (Issue #9595)
バクダンくん
Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
By using :import with relative paths like :import '../private/something.vim, plugin packages can have "private" functions/variables that are not reliably available from other packages. This method is used in my plugin qline.vim.
However, :import must be at the script level now, and the scripts to be imported are loaded when the :import occur, therefore Vim9 loads every related scripts at a time, which makes Vim's startup slow.
I have thought :import autoload will solve this problem, but I found that is not allowed for relative paths.
Describe the solution you'd like
To provide a way to import scripts at relative paths delaying its loading, allow :import autoload for relative (and hopefully absolute) paths.
I don't want those imported things to be available by autoload#names.
Describe alternatives you've considered
Provide a way to make package-local functions/variables. My method is not perfect because those "private" scripts can be imported from other packages if their location is predictable.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
バクダンくん
Describe alternatives you've considered
Provide a way to make package-local functions/variables. My method is not perfect because those "private" scripts can be imported from other packages if their location is predictable.
Well, this may not be the solution for that Vim's startup gets slow.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
So, it appears you would like to use "import autoload", but not allow other scripts to use these autoload scripts?
I don't think you can make this work on the importing side, since the scripts could still be loaded in other ways, e.g. by full path name. Therefore it appears something in the auto-loaded script is needed.
Perhaps you can use expand('') to check if the autoload script was imported by a "permitted" script.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
バクダンくん
So, it appears you would like to use "import autoload", but not allow other scripts to use these autoload scripts?
Yes, I want to keep my autoload scripts un-importable from other packages, or, make private scripts and auto-load them.
It is because I don't expect them to be used from other scripts.
Perhaps you can use expand('') to check if the autoload script was imported by a "permitted" script.
Did you mean expand('<stack>')? That does not work because the autoload script is marked as loaded after first import, whether it was from permitted script or not.
If the first importer was permitted script, exported things are available from all scripts. Otherwise, nothing is exported on loading, therefore even permitted scripts cannot find exported things.
I proposed the feature in the subject in order to make my scripts at least a bit harder to import from other scripts.
I assumed that is not so difficult than other possible solutions.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
You are right, once an autoload script has been loaded the items in it can be accessed with "path#name" by anyone.
So you would like to auto-load the script, but not have its items found with "path#name". That is going to be very difficult, I'm afraid. The current implementation fully depends on these names.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
lacygoill
So you would like to auto-load the script, but not have its items found with "path#name". That is going to be very difficult, I'm afraid. The current implementation fully depends on these names.
Could we add expand('<SID>') in front of path#name?
<SNR>123_path#name
That would make it relatively private for other scripts.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
bfrg
Maybe a new import() or require() function could be added that lazy-loads a script? I don't know if that's feasible, just a thought.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> Maybe a new `import()` or `require()` function could be added that
> lazy-loads a script? I don't know if that's feasible, just a thought.
that what is at the script level doesn't change at runtime. This helps
making compiled functions faster.
One could declare variables, for example a function reference, and the
later set it from a lacy-imported script. Something like:
if !loaded
loaded = true
import './lib/somefile.vim'
FuncRef = somefile.TheFunc
endif
The import would then only exist temporarily. This requires referencing
each item separately. And it won't work for variables.
Another possibility is to make "import" a variable type. Then you could
load it later. This is also a complex thing to implement. Not really
better than a lazy-loaded import.
The original idea of auto-loading a script by relative path still makes
the most sense. Could call this a lazy import:
import lazy '../lib/somestuff' as 'stuff'
As mentioned, this isn't easy to implement. And it will have runtime
overhead accessing the items, like with autoload scripts. Otherwise
this mechanism makes more sense than alternatives.
--
I bought a book on hair loss, but the pages kept falling out.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
lacygoill
Could call this a lazy import:
The name lazy sounds confusing, because import autoload is also a lazy import. If the purpose of this new syntax is to make an imported script private, the name of the argument should reflect that. So, how about import private, instead of import lazy?
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > Could call this a lazy import:
>
> The name `lazy` sounds confusing, because `import autoload` is also a
> lazy import. If the purpose of this new syntax is to make an imported
> script private, the name of the argument should reflect that. So, how
The import is always local to the script. You can't make the imported
script private, it can still be sourced in other ways.
The term "lazy loading" is well known. "autoload" has the special
meaning that the files are searched for in the autoload directories
under 'runtimepath'.
--
SIGFUN -- signature too funny (core dumped)
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
バクダンくん
The ideal behavior has been implemented in Vim 8.2.4650.
Thank you very much!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
バクダンくん
Closed #9595.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.