Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork366
Add configuration value for what auto-require adds#3201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Auto-require always adds the `require` function specifically. However,it's common in projects to have their own special `require` functions,like `import` or `include` -- so this PR adds a configuration optionwhich lets you change what it imports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Pull Request Overview
This PR introduces a configurable option to customize the auto-require insertion function, allowing users to override the default "require" with alternatives such as "import" or "include".
- Updated autoRequire logic to fetch the function name from configuration
- Added corresponding configuration entry in the template and updated documentation and locales
- Updated changelog to highlight the new setting
Reviewed Changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| script/core/command/autoRequire.lua | Uses config to dynamically set the require function in auto-require |
| script/config/template.lua | Adds a new configuration setting for the require function |
| locale/*/setting.lua | Updates locale files with a new setting; translations need completing |
| doc/*/config.md | Documents the new configuration option |
| changelog.md | Updates changelog with new setting information |
Comments suppressed due to low confidence (2)
script/core/command/autoRequire.lua:123
- Consider adding unit tests to verify that the auto-require functionality correctly uses the configured function name instead of a hard-coded value.
local requireName = config.get(uri, "Lua.completion.requireFunction")locale/zh-tw/setting.lua:182
- Update the TODO translation in this locale to provide a proper translated string for clarity.
config.completion.requireFunction = -- TODO: need translate!I believe I think it would make more sense to build this functionality into that setting, rather than adding a whole new setting. |
|
I do wonder actually -- could the auto completion system somehow be exposed to plugins? That'd solve the issue I'm trying to solve here, while also solving#3202. Since we have strict requirements for our codebase (and also mess with paths a little) it'd be great if we could handle how it works ourselves. Unfortunately I wouldn't know how to program that -- but that'd solve a lot of my problems, including some which I haven't talked about (mainly the path stuff), and I'm more than sure that this sort of system would solve problems for others as well.@sumneko I'm curious what you think about such a system; I was thinking for a bit that I'd make my own helper extension for my project, but something like this incorporated into the Lua language server itself would be a great step in customizability & allowing different setups than expected! |
Uh oh!
There was an error while loading.Please reload this page.
Auto-require always adds the
requirefunction specifically. However, it's common in projects to have their own specialrequirefunctions, likeimportorinclude-- so this PR adds a configuration option which lets you change what it imports.Lua.completion.requireFunctiondefaults to"require". I think I did this right?This is open as a draft because I'm unable to test this -- I don't fully understand the environment or how to debug this project. If someone could test this, it'd be great. (The built exe did nothing when ran, unlike the exe included in VSCode... not really sure what's happening there.)