Comments (9)
Just giving a little status update on this; I am still not sure when it will be done, but it's the next thing on my list for the project.
from nwscript-ee-language-server.
Personally, I don't think the LSP should try to resolve priorities here. I think it's enough to collapse all of the scripts offline (starting with base_scripts.bif
, blitting ovr
on top of it) and generate a database, nwscript.nss
-style. If someone has a script in development or override or any number of places, they should add those places to their workspace IMO. The only thing we need to be careful about is when a user overrides the script with one in their workspace - for example if they have a local copy of x3_inc_string
, the symbols from the offline database for that file should no longer show up in autocomplete, they should instead be sourced from the script in the workspace.
from nwscript-ee-language-server.
+1. This would be an excellent feature. I've noticed this regularly when coding Nui.
from nwscript-ee-language-server.
FYI, I had some success from extracing all of the scripts then adding a symlink to my workspace. Then I get syntax highlighting for most scripts - some (like nw_inc_nui) causes errors in the plugin though, see #31.
from nwscript-ee-language-server.
This would indeed be a good addition.
I think what would be best is to generate the complex tokens for those files, juste like we do for nwscript.nss
. We could read the json file here - I would ouput the tokens for these files in an other single file - and then use them in the CompletionItemsProvider
and in the HoverProvider
.
What do you guys think?
from nwscript-ee-language-server.
What happens if users edit the base script (thus bringing it into their module)? I think we'd need to make certain that we only use the offline generated tokens for these files if a script matching that name isn't found in the workspace. In a similar vein, the tokens from base_scripts.bif
would need to be overriden by scripts in the ovr
folder.
from nwscript-ee-language-server.
This is going to be a complex issue. Base scripts can be overridden by scripts of the same name in a module, or a script in the development folder, or by scripts in the ovr folder, or even scripts in a hak file. We'd likely have to determine a priority for these. I don't know if selectively ignoring a previously indexed file is possible, but re-running indexing on all of the organic scripts because one file had been added is probably a huge waste of time and resources.
If it's possible, it's likely best to investigate selective ignoring first. There might be something here as I've noticed that, in some cases that I have files of the same name in different folders, the file I want to use isn't always the one that is used. This would also aid in a feature that only uses indexed files from the current project instead of every .nss file found.
I know this isn't much help. I'll see if I can dive into indexing at some point.
from nwscript-ee-language-server.
What happens if users edit the base script (thus bringing it into their module)? I think we'd need to make certain that we only use the offline generated tokens for these files if a script matching that name isn't found in the workspace.
This is not an issue as the LSP always look for tokens in the indexed files before looking at the static ones.
In a similar vein, the tokens from
base_scripts.bif
would need to be overriden by scripts in theovr
folder.
This is going to be a complex issue. Base scripts can be overridden by scripts of the same name in a module, or a script in the development folder, or by scripts in the ovr folder, or even scripts in a hak file. We'd likely have to determine a priority for these. I don't know if selectively ignoring a previously indexed file is possible, but re-running indexing on all of the organic scripts because one file had been added is probably a huge waste of time and resources.
I am not really sure what is the best solution for this yet, but I really think LSP files management should be kept for files inside the project. The LSP has good control over those files because of the event notifications sent by the client, it will be really hard however to handle correctly files in other locations.
I will have to think about this and you are welcome to participate to the process and even implement it ultimately if you want to.
from nwscript-ee-language-server.
That sounds like a great start. If local definitions from the workspace override those in the json/database for the base scripts and nwscript, the appropriate behavior should automatically resolve itself. Now, we'll just have to work out finding and indexing those files with, if course, being sure not to include any old nwscript.nss that might be hanging around.
from nwscript-ee-language-server.
Related Issues (20)
- Non-included script indexing/use
- Diagnostics compiler error on Windows HOT 2
- Error when adding ovr folder as a symlink in workspace directory to get syntax highlighting for nw_inc_nui HOT 2
- Problems remain after file closure HOT 4
- More nw_inc_nui shenanigans! HOT 3
- Constant Regex not recognizing legal constant HOT 1
- Publish automatically on vscode marketplace and repo HOT 1
- Add tests HOT 1
- Lower extension size
- Constants highlighting does not recognize operators HOT 1
- Error detail no longer reported in 1.5.3 HOT 2
- Symbol Information Missing. HOT 4
- 1.5.4 Indexer Issue HOT 2
- Update to latest compiler version
- 2.0.0 Intermittently Stops Working HOT 6
- nwnsc not terminating after done compiling HOT 1
- Struct Member Completion Issue HOT 2
- Diagnostics: Change nwnsc for nwn_script_comp HOT 1
- Formatter bug HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nwscript-ee-language-server.