A new TESH Syntax Highlighter for Warcraft 3

1. Looks like the hex in styles.ini might be backwards.
   eg. 0xD8AB70 == rgb(216,171,112)
   but you're saving that rgb value as 0x70ABD8.
   
   It 's not an issue unless someone tries to edit the styles.ini manually, in which case they need to put in the hex values backwards.
2. Also a minor nitpick re styles.ini, what's the reasoning for enforcing
   ```
   blah.backcolor=0x...
   blah.backcolor_index=1
   ```
   only to hide it with `blah.transparent=1`.
   Surely these could all just be unset by default, and then setting them would override the background colour?
   
3. Worldedit hangs on closing if tesh has been started up during that session, sending me through two forcequite cycles before it finally gives up and goes away. (wc3 tft 1.28, cannot confirm if this is new, or if it affects 1.27b as well).

Rest looks pretty sweet!
More feedback to come later.

 

Thanks for the feedback.

Yes thats right. This is because COLORREF stores colors in BGR order.

Maybe I will change that to store RGB, however I don't really see a reason why someone would modify the styles.ini manually.

Actually there is a pretty massive amount of plausibility checks implemented in the option file parser to avoid that manual modifications of this file can lead to undesired effects/crashes. So, it is not neccessary to manually modify that file: every possible option can also be set from within the WE.

Its not hidden, the color is actually used. There are several things to consider here, I have put quite some time in thinking this through before implementing this. Let me explain:

Typically, when users change the backcolor of the whole editor (the background of the editor itself), it is expected that other styles also change their backcolor "automatically". I.e. that they behave as if transparent.

For example, if I want to use a dark backcolor style, I usually just want to change the editor backcolor to black. I don't want to set the backcolor of all other styles manually to black as well, because thats redundant and tedious work. Therefore changing the editor backcolor should change other styles backcolors as well.

However, what happens if for some styles, I actually want to have a different backcolor. Then I don't want that this information is lost/overwritten when changing the editor backcolor.

There are basically two approaches to resolve this issue:

1. Change only the backcolor of styles automatically, that had the same backcolor as the editor backcolor before the change was requested.
2. Use a seperate flag to let the user configure which style should be "transparent". This is what is done in TESH 2.0.

So, why was the second option chosen over the first? Because it gives the user more flexibility by avoiding undesirable effects: Imagine your editor backcolor is white, the backcolor of, say, native types is red. Now the user changes the editor backcolor to red. After that, the user changes the editor backcolor to green. If method 1.) was used, the algorithm would have no way to detect that native type backcolor should actually stay red, regardless of the editor backcolor.

With option 2.) this is easily possible. It gives better control of style handling to the user. Therefore, this option was chosen for TESH 2.0.

Why I write "transparent" in double quotes?

Because the backcolor of the styles are not really transparent. Behind the scenes, if set to transparent, they look up the editor backcolor and just use this one.

Yes, I have already identified (and fixed) that issue, will release a patch for this soon.

Thanks, looking forward for that.

 

Hehe, well i tried to translate my old config into your format, and felt it'd be quicker to just edit the styles.ini directly.
I got it all to work, cept my colours turned out inverted. XD Trust Microsoft to make things weird. I'd suggest fixing this, though it's not huge priority. It just causes unnecessary confusion.
In this vein, it would be sweet if there was a button in the WE TESH style editor section to reload from the styles.ini (i had to restart wc3 each time lol). Using the interface is a bit slow, esp since it doesn't let you feed in hex directly.

Sure, but couldn't these just be left unset? ie if `text.backcolor` doesn't exist in the styles.ini file, use editor_background.backcolor in its stead. If it is set, use it. Then there is no issue with unintentionally overriding settings, as when the user selects a different global backcolour, only the editor_background.backcolor value changes in styles.ini. Everything else simply defaults to this backcolour if nothing else is set. If they want a different backcolour for something, eg `selection.backcolor`, then when they set this, `selection.backcolor` is explicitly added to styles.ini.
The old tesh used `backcolour=default` for these cases, but even that was superfluous imo. Just not including it in the file is enough. Then you might not even need the "transparent" flag.

 

Ok, that makes sense.

Will be added in the next patch.

So you only meant why it is stored in the styles.ini like that, right?

Well, it could also be implemented like you explained. However, I don't really see an advantage over the way how it is done at the moment. I prefer to have everything explicitly stated in the file, because the structure of the file is then always the same and there are no implicit settings obscuring any options from the user. Also it avoids inconsistent states like setting transparent to 0 manually in the file, while not specifying a backcolor.

Of course that could again be checked when the file is read, but I prefer that if users want to modify the file manually, they at least have all options to modify there directly - without adding or deleting any lines, but just changing values.

However, I will probably display the transparent flag differently in the file... maybe just like text.backcolor=transparent instead of specifying the color itself.

Yes, there are some differences... which JNGP replacement did you use? Which OS are you using and do you get any error messages?

 

Awesome, thanks

Sounds good!

wat? JNGP2.0?

 

Ok, I will take a look into this, thanks for the feedback.

Well, I don't really want to have multiple versions around at the same time... at least if that can be avoided. I think having just one single version that works for everything is better and avoids confusions.

Hm, did I miss something?

 

This sometimes crashes the WE when I open a trigger. But it's quite rare to happen, and it can happen to any trigger. Is it somewhat related to the patch 1.27b I'm using?

 

Looks like it's different. For me it never crashed when I save maps. Only happen when I open a trigger.

 

Not sure if it is TESH related, but this is the first time I encountered run-time error while using WE with TESH 2.0. Here is the image :

Run-time Error

And another thing is, although not a big deal, WE tends to crash while I close it, and appear to have this error message before the crash message :

Error

 

Now fully WEX and Sharpcraft compatible. Also fixed quite some small bugs. Styles can now be reloaded at runtime. Tabs and spaces are now handled "as expected".

Update to version 0.9.1

• Fixed a crash when closing WE
• Added compatibility with WEX and Sharpcraft
• Fixed that sometimes, text window was displayed over GUI
• Fixed short flickering of the editor when starting WE starts for the first time
• Added the option to load style themes at runtime
• Fixed that under some circumstances, function list text could be modified
• Fixed tabs to spaces does not take into account effective tab length
• Fixed spaces to tabs does not take into account effective tab length
• Added the option to use spaces instead of tabs
• Fixed loading special characters from template files causing wrong encoding
• Fixed error on loading trigger editor name from file containing unicode characters
• Added an exported function to the dll to set the search string for the TE window programmatically
• Changed all predefined templates from using tabs to using spaces by default
• Styles are now stored as RGB instead of BGR in the styles.ini file
  

And attached an image of the new option dialog.

Options

Looking forward for feedback.

 

0.9.1 can't open files (options/style) if it is located in a folder with non ASCII characters:



If I move WEX in a folder without greek characters the options/style/function.db load correctly.

 

I also noticed a strange issue with font rendering.
I changed my font to Consolas, and noticed that even though the font is monospaced the space size was not the same as the character size. Changing the font size to 11 for consolas it renders as a proper monospaced font but any other size renders wrong.
Trying with Courier New the font remains monospaced for any font size up to size 10. Any higher than that and the spacing is wrong.

Also what does "Filter legacy TESH scroll/fold info"? Does it remove those two line left by the old TESH, or does it use them to restore the last editor state?

 

Will be fixed in the next patch.

Will take a look into this, thanks.

It just removes the two lines if they exist (if unticked, the two lines are not removed).

In theory this legacy trigger state info could be used by TESH 2.0 as well to restore the last editor state. However, it doesn't really make sense because both fold and scroll state are already stored internally in the new TESH. So whenever you switch to a new trigger and then move back, both the fold and scroll state will be restored without modifying the trigger script. This has the benefit that the dirty flag isn't raised for the TE.

 

Tnx

 

I also had a crash the first time I used it. For me it happened when I opened another trigger, and hasn't happened since so I have no Idea how to reproduce it.