jsmorley wrote:1) Missing "ScriptFile=" (I missed it too in my latest UserDefineLang)
2) I gather you are not going to highlight the "value" part of Key=Value when there are defined options?
Meter=Image
Measure=Calc
StringStyle=Bold
I'd miss that... I make as many mistakes with improper values as I do with improper keys.
3) It doesn't seem to be highlighting bang names like !RainmeterSetVariable or built-in variables like #CURRENTPATH#, or plugin names like WebParser.dll Is this intended? I depend on those.
1) Will add, thanks.
2) Yeah, that'll be added for sure, possibly with some cool stuff. Forgot to write about that in starting post, read the 'Planned features' in a minute or two.
3) It highlights !RainmeterSetVariable (and all other bangs) fine. Can you post your .ini so I can take a look at why it doesn't?
Any way possible for you to add a "Save and Refresh Skin" option? If you could also have it minimize NP++ so you can see the refreshed skin that would be cool.
dragonmage wrote:Any way possible for you to add a "Save and Refresh Skin" option? If you could also have it minimize NP++ so you can see the refreshed skin that would be cool.
That's really not what lexers are designed for. Perhaps the Run -> Run... feature in Notepad++ could be used for this?
Any changes like that would take an extremely customized Notepad++ itself. I'd never use it, but as long as the lexer dll plugin isn't tied to a custom Notepad++ in such a way that it is all or nothing, than go for it.
I really like where the lexer is going, and will use that indeed. I have no interest in a custom Notepad++.exe. I want the official version, and I want betas and releases as soon as I see them.
Just for me personally, I see no reason at all to mess around saving one or two mouse clicks by adding "refresh this skin" to Notepad++ and have to add the ten tons of code it would take to integrate Notepad++ with Rainmeter so it can send the right bangs to the right configs and all that, and then have to keep that current with Notepad++ releases.
Actually I'm pretty sure NP++'s plugin architecture would easily allow for a plugin that is completely independent of the core of NP++. As NP++ already has the path to the ini the configname should be easy to figure out. Worst case scenario you might have to enter a path to Rainmeter.exe into the plugin. I know, "easier said than done" but I doubt it is that difficult. I have to start learning to code on my own...
dragonmage wrote:Actually I'm pretty sure NP++'s plugin architecture would easily allow for a plugin that is completely independent of the core of NP++. As NP++ already has the path to the ini the configname should be easy to figure out. Worst case scenario you might have to enter a path to Rainmeter.exe into the plugin. I know, "easier said than done" but I doubt it is that difficult. I have to start learning to code on my own...
You may be right. Notepad++ does have a pretty robust plugin system, in fact it is how most everything other than basic features are implemented, like spell check. Might be worth looking into someday, but it's not a feature set I really care about anyway. I keep RainBrowser open on my second monitor while coding skins and that gives me the tools I need in one place. I'm going to concentrate on getting my C# and Lua skills up from disgraceful to miserable for now. How did I end up so involved with a desktop application after 20 years of server and Web development?
I've implemented a slew of additions, but before I release anything I have a few questions.
- Should auto-complete for keywords include the equals sign (i.e. Keyname= vs. Keyname)?
- Should options be highlighted when valid or when invalid (StringCase=UPPER/StringCase=BLAA vs. StringCase=UPPER/StringCase=BLAA)? I prefer highlighting when invalid.
Here is the changelog so far:
- Added auto-complete
- Added separate highlighting for internal (e.g. #SKINSPATH#) and external variables (e.g. #CUSTOMVAR#)
- Added highlighting for invalid lines and options
- Added highlighting for special keywords such as ScaleN and LocalFontN
- Added separate highlighting for the equals sign in (in Keyword=Value)
- Improved logic and performance
poiru wrote:- Should auto-complete for keywords include the equals sign (i.e. Keyname= vs. Keyname)?
- Should options be highlighted when valid or when invalid (StringCase=UPPER/StringCase=BLAA vs. StringCase=UPPER/StringCase=BLAA)? I prefer highlighting when invalid.
I vote autocomplete should include equal signs.
And I agre highlighted when invalid. Highlighted stands out, while the normal text blends in and you're more prone to skim over it.
I prefer highlighting valid values. With how key names highlight when valid, it just makes sense that the values should follow the same rule.
GitHub | DeviantArt | Tumblr
This is the song that never ends. It just goes on and on my friends. Some people started singing it not knowing what it was, and they'll continue singing it forever just because . . .