enh(nsis) adds NSIS v3.08 commands, some small improvements

[idleberg]

Changes

Adds NSIS v3.08 commands
Fixes case sensitivity option

Checklist

• Added markup tests, or they don't apply here because...
• Updated the changelog at CHANGES.md

[joshgoebel]

I changed the constants to variable.constant. I wonder if all the many "keywords" should become built_in or function.name... they look more like utility functions than proper keywords.

PARAM_NAMES is a little confusing also... do any of the newer scopes we're using apply perhaps?

[joshgoebel]

Also, what is nsExec::ExecToLog "calc.exe" here exactly? class as a scope has been deprecated, so we need a new scope.

[idleberg]

Also, what is nsExec::ExecToLog "calc.exe" here exactly?

In NSIS terms, it's a command (ExecToLog) provided by a plugin (nsExec). While most plugins are third-party projects that can be installed by users of NSIS, there are several first-party plugins bundled with NSIS (AdvSplash, Banner, BgImage, Dialer, InstallOptions, LangDLL, Math, nsDialogs, nsExec, NSISdl, Splash, StartMenu, System, TypeLib, UserInfo and VPatch). I hope this helps to find a better classification for plugin commands.

[joshgoebel]

In NSIS terms, it's a command (ExecToLog) provided by a plugin (nsExec).

I'm thinking:

<title.function>nsExec::ExecToLog</>

or

<title.class>nsExec</>::<title.function>ExecToLog</>

Thoughts? title.function is most similar to what we were doing before and obviously the latter draw more of a distinction between the module name and the functions it provides.

[joshgoebel]

@idleberg That was an either/or question. :)

[idleberg]

You probably have a better overview if there are similar cases in other languages and can make a better decision on how these cases should be treated. Semantically, the latter proposal makes sense to me. On the other hand, there are no use cases for a class alone, one can only use the combination of a class and a method (class::function). So maybe there is no practical sense to use different scopes. Personally, I have no preference really. It would be nice to get another opinion on this, but I doubt the interest in NSIS is high enough to get one.

[joshgoebel]

Personally, I have no preference really.

Fair enough... but ask yourself: Would you find one or the other easier to read in a highlighted code snippet? That's kind of what I was getting at.

@allejo Any thoughts?

[allejo]

Hello 👋

Coming from other programming languages, having a differentiation between a class name and a function is helpful in terms of highlighting but that's because they each carry a separate meaning on their own.

Based solely on this conversation, it sounds to me that since you can't have a class by itself in NSIS then highlighting them separately wouldn't really carry any useful meaning. To me, this behavior sounds a lot more like a namespace rather than a class, like you'd see in C++ with std::string and std::string::npos; I'd expect both of these values to be highlighted as a single value instead of std being a "class."

My vote would be to highlight it as,

<title.function>nsExec::ExecToLog</>

[joshgoebel]

Added highlighting for Function blah and Function .blah style patterns back. I think this is good to go now.

[joshgoebel]

@idleberg Thanks so much. This will land in 11.3, hopefully this week.