Re: [vim/vim] Refined autoload mechanism explanation (PR #20833)
ubaldot (Vim Github Repository) <[email protected]>
| Newsgroups | gmane.editors.vim.devel |
|---|---|
| Message-ID | <vim/vim/pull/20833/[email protected]> |
ubaldot left a comment (vim/vim#20833)
I updated the PR by addressing the reviewers comments as it follows:
1. The implications of having a script in an autoload/ folder has been highlighted even more clearly now,
2. The remark on the effect of re-sourcing a Vim9 script has been removed, and a link to the reference manual has provided as requested (even if prose in the referenced link is somehow "terse"),
3. Broken links should be fixed by now,
4. Documentation style has been aligned with the rest of `:help` guidelines,
4. I agree, that the example with the `globpath` is not robust (it was already mentioned in the previous version), but I also agree that a distracted user could just copy and paste the example, despite it may fail in some corner cases. Hence, I completely removed the hint as requested, we can leave users alone to figure out how to import symbols by themselves for this use case,
5. The review about Section 5.4 is not correct. The differences between the two examples can be easily spotted at first sight, as I explain next:
The example in 52.4 works as it follows:
- First source: `s:did_load` does not exist, so the if block runs: commands and mappings are defined, `s:did_load` is set to 1, a `FuncUndefined` autocommand is registered, and then finish exits early. The functions at the bottom of the script are not loaded yet.
- Second source (triggered only when a `BufNet*` function is actually called): ` s:did_load` exists, so the if block is skipped and the functions are defined.
This is a deferred loading mechanism: the heavy part of the script is never loaded unless the user actually invokes the functionality.
The vim9script `noclear` plus `exists('*SomeFunc')` pattern, by contrast, is a run-once guard: it prevents re-sourcing from redefining symbols, but it loads everything on the first source. It is not a replacement for 52.4.
Regarding the applicability of the strategy for lazy loading described in 52.4 in Vim9, I voluntarily left it out from the help file because in-spite there is a strong evidence that such a method only applies to vim-legacy, I don't have a formal proof. Nevertheless, I thought it was at least worth mentioning it here.
Note that the reviewer mentioned that he/she used Claude code for the review task. However, the review mentioned in point 5., which suggests the equivalence of the two examples, may have been taken at face value without any deeper verification, which I agree that it is something that could happen when doing AI-assisted work. This is a good reminder that AI tools are helpful for spotting style issues, but technical questions should still be carefully reviewed by human reasoning.
--
Reply to this email directly or view it on GitHub:
https://github.com/vim/vim/pull/20833#issuecomment-5084221979
You are receiving this because you are subscribed to this thread.
Message ID: <vim/vim/pull/20833/[email protected]>
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/vim_dev/vim/vim/pull/20833/c5084221979%40github.com.