Paradox-Language-Support
Paradox-Language-Support copied to clipboard
DragonKnightOfBreeze
Inference for inline_script parameters from usages
As we expand the use of inline scripts in Gigastructural Engineering, it has become useful in several places to pass whole blocks of code as parameters. It would be very helpful if the parameters could be evaluated, much like how the scripts themselves infer context from where they are used.
I understand that this might be a tricky request to fulfill, but being able to catch typos in these situations without making mock-ups first would be super useful.
Thank you, once again, for all of your hard work.
While the first option can enable the argument value inference (for scripted_triggers, scripted_effects, inline_scripts, single value or multiline), the second option can enable the inline script inference (for inline script files). And the leaving three options enable scope context inference in several situations, which may significantly affects performance.
If it's not work:
- There may be a bug, just update to 1.2.5.
- The case may be too complex.
Well, those settings are already enabled:
The current version of the plugin which I have is 1.2.4, but that's also the newest version the plugin settings give me...
A minimal example script which just takes one parameter and places it in-situ is the simplest case that I can think of
But when it's used the parameter doesn't seem to be checked at all, and doesn't receive syntax highlighting.
So I'm not sure if I'm understanding what those settings are meant to be doing correctly.
Update plugin to 1.2.5 on github releases and see what happens?
Also open xxx_traits.txt and see what happens to the inline script usages in these files?
I think I see what's going on now.
The trait files seem to work correctly, and if I add a second parameter which is the right hand side of an expression, like this:
Then that parameter seems to work as expected, but the one which is meant to just put its whole content there does not.
It seems to understand situations where the passed parameter is the right side of an expression, but not where it's a scope, or when it's a whole line or multiple lines.
A question, when typo modifier after v = , should plugin provide completion items and make inserted text surrounding with double quotes after applied, or just do not provide completion items (for there are no double quotes after v = and whole line or multiline parameter value must be used in double quotes) ?
I am not entirely sure what you mean, but I do think it should still provide completion when typing inside quotes.
I think the ideal behaviour would be if it acted the same as a normal code block when inside quotes, almost as if they were braces instead, maybe only when multi-line? Unsure.
If I could type inside the parameter and it acts the same as where the code ends up being, that would be perfect - so in the very basic example again:
Thank you for looking into this, it should be really useful for us.
@adriangaro probably has opinions on this too, as the only other person I know of who is doing weird things with inlines.
What do i say is that when I just typo modifier after v = (neither v = " or v = "\n, \n means line break), should plugin provide completions for statements such as modifier = {...}? And if should , also make it surrounds with double quotes, and then, there is some text like v = "modifier = {...}"
Oh! Without quotes it should probably only suggest things which don't need quotes, like possible right-side values for expressions if the parameter is used that way.
Would also be neat if the plugin can't easily infer a type, if somehow we could provide it through a comment in the line or something.
Something like
# @param <param name> - <type>
# so something like below
# @param trigger - trigger block/triggers
Mostly it is an example, but comments should probably avoid the $ symbol since they do get interpolated in the comments too, and with multi line strings they go over next line outside the comment.
The types could be some predefined ones, or somehow some types from the cwt definitions.
I have a lot of cases where the parameters can't be inferred due to using intermediary inlines for indirection/conditional logic, which breaks very quickly any kind of inference of type.
Some examples are
https://github.com/Stellaris-Evolved/stellaris-evolved/blob/V0.9R8/common/inline_scripts/jobs/inline_evolved_job.txt
https://github.com/Stellaris-Evolved/stellaris-evolved/blob/V0.9R8/common/inline_scripts/jobs/inline_evolved_job_no_desc.txt
https://github.com/Stellaris-Evolved/stellaris-evolved/blob/V0.9R8/common/inline_scripts/jobs/inline_evolved_job_with_desc.txt
The first inline calls either of the following two depending on one of the parameters passed to the first one and delegates the rest.
Also due to the interpolation of the $job$ parameter into the modifier, the plugin has no idea that parameter is a job, so no autocomplete.
Being able to annotate that job is of the type job, would allow better highlighting.
I know it's a tall ask but would be really cool to be able to annotate parameters types, and maybe even add docs so they appear in context windows.
If type annotation/comments are added, especially for triggered blocks, it would be amazing if the scope type could also be specified. (Yet again this is a nice to have in the context of inline script parameters, or parameters in general).
Thanks for the amazing work as always!
Another case for annotation would be for union types for a parameter, if it can take some specific values.
In the inlines above, display is such a variable which can access only some specific values.
Probably for this maybe, the enunarations could somehow be declared in the project as a cwt definition and referenced?
Mostly spitballing on this, so take everything with a grain of salt, whichever variant would be easiest (if it will get handled) for type annotations, I'll be extremely happy.
Magic comment or annotation comment is a good idea since it's already used by JetBrains officially in various template languages (e.g. JSP and FreeMarker), and I once considered this way. But, the standards are to be determined, these is not only type annotation comments (or, cwt config annotation comments), but also some documentation comments and even scope context comments.
Paradox-Language-Support-1.2.6.zip
Here is a pre-release to support inference for whole line / multiline parameter values
Happy to say the first example above is highlighting now, but sadly it seems to be too complex for the plugin to properly infer context for, probably due to an inline call in the chain using a parameter in the script name.
This is so much nicer than before though, so thank you!
What about inference for these inline script files, does it work well?
More simple scripts work very well:
The ones in the previous message don't, but that's probably because of these:
giga_switch
giga_toggled_code
Which conditionally leads to two scripts, giga_toggled_code_case_0 and giga_toggled_code_case_1, the first of which is empty, for only including code if the $toggle$ input is non-zero.
Technically speaking even if they were to infer everything correctly it would still break, as those toggles would resolve to 0 due to being cross-mod compatibility values, 0 when the other mod is not loaded and overwritten by that other mod to be 1.
So if the plugin somehow manages to untangle the flow in there, it would always end up leading to the empty giga_toggled_code_case_0 because has_bug_branch is always zero in our development environment.
Some kind of override annotation would be required at very least to point it at giga_toggled_code_case_1 instead, perhaps by telling giga_switch to always consider its value parameter to be 1 for the sake of inference, or to treat has_bug_branch as 1 or something... it's awkward.
Emmmmmmmmmmmmm... How do Chinese modders comment on your foxy?
I... don't understand what you mean.
What I mean to say by the previous comment is that I realised that the inference could never work for that particular script without extra hints because of the way we have structured it. It would always discard the parameters because their use is conditional upon another mod being present (because has_bug_branch is 0 when the Bug Branch mod is not present).
It seems to be working very well outside of those very complicated situations though, thank you for your efforts.
What I mean is that ... these are too many usages of paradox scripts' advance (or even very tricky) features in your mods, and so do some Chinese moddders'. Is may be sometimes necessary and convenient, but it also make paradox's languages not simple (or, not simple txt), and so do my plugin and cwtools.
I expected this case would probably be too complex to reasonably parse, I didn't mean for it to sound like a complaint or anything. It is an ideal example of where an annotation could be useful though.
I found out that the best way to provide advance language featues for implicit things, like parameter an event target's scope context, is just extended cwt config, rather than special comment in script files, or stupid inference.