A new TESH Syntax Highlighter for Warcraft 3

[looking_for_help]

Ok, hotfix is available. The bug should be fixed now, together with some other smaller ones. Also the warning message when reactivating a disabled trigger (for example with CTRL-I) is now supressed.

Update to Version 0.5.5
- Fixed a bug that the trigger window sometimes wasn't detected correctly
- Fixed a bug that the trigger window stayed open when closing the map
- Fixed a bug that pressing on the options button removed some fold headers (was a remainder of some debug tests)
- Pressing ESC in Find-Window now closes the window instead of performing a replace
- Warning message when re-activating a disabled trigger is now supressed

 

[Cokemonkey11]

Installed, will let you know if I have any new problems

 

[Ice Snake]

Very good, I think if you can add this feature, a feature from Notepad++ to the new generation of TESH then will be much better:

- Notepad++ have a feature that highlight all the same word as selected word, here it is:

Very useful when manage a big project or just modify, recheck code.

 

[pred1980]

a nice small feature from Zend Studio.

Press STRG+D deletes a complete line.

STRG+SHIFT+C sets a marked code in comments..
That means, if one line is marked it makes //
If more than one are marked it makes
/*
* code...
* more code...
*/

 

[looking_for_help]

Very good, I think if you can add this feature, a feature from Notepad++ to the new generation of TESH then will be much better:

Press STRG+D deletes a complete line.

Accepted.

STRG+SHIFT+C sets a marked code in comments..
That means, if one line is marked it makes //
If more than one are marked it makes
/*
* code...
* more code...
*/

Yes, I thought about that too, but I think I will make multiple selected lines also commented out by // line-comments. I think this is more useful, because block-comments are stopped at */ and vJass doesn't allow nested blockcomments (which is quite annoying).

Thanks for the suggestions.

 

[LeP]

Accepted.




Yes, I thought about that too, but I think I will make multiple selected lines also commented out by // line-comments. I think this is more useful, because block-comments are stopped at */ and vJass doesn't allow nested blockcomments (which is quite annoying).

Thanks for the suggestions.

call BJDebugMsg/* but
               /* it does */
                 mate */("http://wc3c.net/vexorian/jasshelpermanual.html#delicom")

 

[looking_for_help]

call BJDebugMsg/* but
               /* it does */
                 mate */("http://wc3c.net/vexorian/jasshelpermanual.html#delicom")

Yes, but only if they are closed, which is quite inconsistent in my opinion. Something like:

/* This is stupid /* because it throws an error for no reason */

will not compile. But the main reason why I think linecomments would make more sense is that you can add a blockcomment very fast manually, while commenting out 100 lines manually with linecomments (if, for some reason you prefer it this way) takes nuch more time.

But I think I will wait for a few opinions about this topic, so if you have arguments for or against, please let me know.

 

[muzzel]

Linecomments all the way~ thats what all IDEs do.

 

[LeP]

Yes, but only if they are closed, which is quite inconsistent in my opinion. Something like:

/* This is stupid /* because it throws an error for no reason */

will not compile.
[…]

That's good and intended behavior. Just like parentheses: you open one, you close one.
It allows me to comment out a block in which i already commented out another block.
There is literally no inconsistency in that. An opening function needs one closing endfunction.
An opening loop needs one closing endloop…

Languages where multi line comments are not nested are actually shit and inconsistent.

 

[looking_for_help]

Languages where multi line comments are not nested are actually shit and inconsistent.

Then languages like C, C++, C# or Java are shit for you? Interesting.

For me a comment means that I can make anything inside it without causing syntax errors. But this discussion which way is better is quite senseless because it is purely based on personal preferences. I already made a point why I prefer Line-Comments, just because it takes much more time to Comment out many lines with Line-Comments manually. Also in most IDEs its done like that, as muzzel said.

But thanks for the feedback, I will wait for some more opinions.

 

[LeP]

Then languages like C, C++, C# or Java are shit for you? Interesting.

Yes, it's quite annoying to comment code-blocks in C. All other languages only inherited that behavior. Historic reasons are best reasons.
Once you worked with a language with nested comments you cringe every time when you have to slowly look that there is no other comment in the block you are about to comment.
Just tedious.

For me a comment means that I can make anything inside it without causing syntax errors.

But that's exactly what nested comments give you. You can take *ANY*¹ code block, wrap it in some comments and it's gone.
With a language w/o nesting comments you get some syntax error when you comment out a block with some multi-line comment.

But this discussion which way is better is quite senseless because it is purely based on personal preferences. I already made a point why I prefer Line-Comments, just because it takes much more time to Comment out many lines with Line-Comments manually. Also in most IDEs its done like that, as muzzel said.

But thanks for the feedback, I will wait for some more opinions.

I don't care what kind of comments you chose for that functionality.
I probably even agree that single-line comments are the right choice.
But i guess the reason those IDEs chose single-line comments is because the languages they operate on have broken multi-line comments and only single-line comments "nest".
And now you want to mimic that behavior because it's familiar. historic reasons upon historic reasons))

1: as long as there is no unmatched closing-comment in there. but that affects languages w/ broken multi-line comments too.

 

[looking_for_help]

Yes, it's quite annoying to comment code-blocks in C. All other languages only inherited that behavior. Historic reasons are best reasons.

Well that might be correct, but I have no problems with commenting out blocks in C. Thats exactly where a shortcut for Line-Comments does the trick.

But that's exactly what nested comments give you.

Not really, not in the sense I mean it. Consider something like this:

Example

function foo takes nothing returns nothing
    local integer i
    /*call BJDebugMsg("test")*/
endfunction

Now I want to change that to:

function foo takes nothing returns nothing
    /*local integer i
    /*call BJDebugMsg("test")*/
endfunction

And there you go, Syntax Error. I now have to search where the block comment ends and close it manually. For me thats annoying. In C++ I can directly concatenate such comment blocks.

But again, thats not really the point here. And it seems you misunderstood something here:

And now you want to mimic that behavior because it's familiar. historic reasons upon historic reasons))

I don't want to mimic anything, I'm not changing the vJass language. I only provide a better highlighter, the logic how comments work will of course remain untouched. So the only thing that is open for discussion here is what comment type should be used by a hotkey, nothing else. Independent of the choice will comments stay nestable.

 

[muzzel]

But i guess the reason those IDEs chose single-line comments is because the languages they operate on have broken multi-line comments and only single-line comments "nest".
And now you want to mimic that behavior because it's familiar. historic reasons upon historic reasons))

Well the thing about humans is that they often dont think and act straight and often prever things they are used to over technically superior alternatives. Messing with that usually doesnt meet with their approval.

So yea, sometimes historical reasons are valid.

 

[LeP]

Not really, not in the sense I mean it. Consider something like this:

Example

function foo takes nothing returns nothing
    local integer i
    /*call BJDebugMsg("test")*/
endfunction

Now I want to change that to:

function foo takes nothing returns nothing
    /*local integer i
    /*call BJDebugMsg("test")*/
endfunction

And there you go, Syntax Error. I now have to search where the line comment ends and close it manually. For me thats annoying. In C++ I can directly concatenate such comment blocks.

I don't know even know what your intention is here.
You want to only comment out the local line? use //
Want to comment out the whole function body: just put /* before the local line and */ after the call and it works. that makes it perfectly clear what blocks you intent to comment out. /* */ are just like { }.

consider this

function foo takes nothing returns nothing
  call some_probably_working_function()
  
  /*
  call some_non_working_function()
  call some_non_working_function()
  */

  call some_probably_working_function_again()

   // function continues here…
endfunction

now i want to comment the two other calls because debugging.

function foo takes nothing returns nothing
  /*
  call some_probably_working_function()
  
  /*
  call some_non_working_function()
  call some_non_working_function()
  */

  call some_probably_working_function_again()
  */

   // function continues here…
endfunction

broken multi-line comments only work backwards while proper multi-line comments actually work in both directions.

yes you can perfectly work backwards but in vjass i'm able to work both directions)


and it's perfectly clear what are you doing. no misunderstanding besides that nesting multi-line comments are obviously objectively superior))

again, i don't care what kind of comments you use for your functionality and
the last bit was just snarky comments about reasoning for // comments to be used for your functionality)

 

[looking_for_help]

and it's perfectly clear what are you doing. no misunderstanding besides that nesting multi-line comments are obviously objectively superior))

I already said that this is purely based on personal preferences. You prefer nested comments, I understood (and accept) that and so should you. You just can't argue personal preferences, thats like saying your favorite ice cream must be chocolate.

I don't know even know what your intention is here.
You want to only comment out the local line? use //
Want to comment out the whole function body: just put /* before the local line and */ after the call and it works. that makes it perfectly clear what blocks you intent to comment out.

Yes and commenting out the whole function body works faster without nested comments because I can directly concatenate comment blocks without having to close them. Just accept it, both approaches have their own advantages, you can't speak of 'objectivity' here just because you prefer it that way.

again, i don't care what kind of comments you use for your functionality and
the last bit was just snarky comments about reasoning for // comments to be used for your functionality)

And thats why I want to end this discussion now.

I gave a very clear reason why to use Line-Comments namely that it safes potentially much more time. And this thread is not meant to discuss things that are not touched by the TESH, so I don't get your problem.

 

[TriggerHappy]

nesting multi-line comments are obviously objectively superior

There's nothing objective about that statement.

I have to agree with LFH, standard multi-line comments are more practical while nested ones can be confusing or redundant.

Although it's up to personal preference, generally people prefer not to have delimited comments.

Anyway, enough off-topic lets just discuss the syntax highlighter.

 

[Cokemonkey11]

    ;everyone knows x86-style comments are objectively the superiorist

after all all code compils 2 assembler so jass comments are for noobs

 

[looking_for_help]

New Update available.

I'm setting this from alpha to beta status, as with this update it is very stable and many minor bugs got fixed, most of them also present in the old tesh. But first the new features:

The Search and Replace window got extended by new search options that the user can specify now. For example the user can now either search from the current caret position or from the top of the trigger. Further the search direction (up or down) can now be specified as well as performing a posix conversion for the search. Here is a screenshot of the new Search and Replace window:

Furthermore the $ operator was added to the syntax highlighter with highlighting text in between two $ operators so that template-types now also get highlighted. Then, indicator highlighting is introduced with this update. This means that all occurances of the word from the current caret position are automatically highlighted by a transparent shadow. Both new features are displayed in the attached screenshot.

Finally, many small bugs were fixed. For example string highlighting with multiple escaped backslashes are now highlighted correct, like for example:

local string s1 = "test \\\\\\" // from here it should be highlighted as comment
local string s2 = "test \\\\\\\" // but from here it should be highlighted as string

which was done wrong by the old tesh as in the second line the comment was highlighted as if the string was closed.

Here is a complete change list:


Update to Version 0.6
- Added indicator highlighting to the current selected word and all its occurances
- Drastically improved perfromance due to better communication with the Wc3 Editor
- Special characters like ü are now added correctly to the Search and Replace history
- Search from Caret option is now supported
- Search and Replace now supports Posix conversion option
- Fixed a bug with undo/redo that could cause invisible lines at fold points
- Fixed a bug with copy/paste that could cause invisible lines at fold points
- Fixed a bug with adding multiple newlines could cause invisible lines at fold points
- Multiple escaped backslashes now don't mess up string highlighting anymore
- Fold all button now no longer keeps the focus when pressed
- Load Template button now sets the focus directly in the onInit method
- Fixed a bug with the Load Template button which could cause invisible fold headers
- Enterering newlines at folded lines now doesn't break folding like in the old tesh
- Fixed a bug when entering only one char on an empty trigger page wasn't sended to the trigger editor
- Added the $ operator to the syntax highligher
- Macro types between the $ operator, like $TYPE$ now also get highlighted
- Added the {} operators to the syntax highlighter
- Curled braces are now also highlighted on good/bad matches
- Added the textmacro_once keyword to the autocomplete list and the folding logic

 

[TriggerHappy]

Nice, I'll probably be updating to this one soon.

 

[PurgeandFire]

Did you ever think of coming up with a different name for this? I'm just curious.

At the moment, I have to refer to it as lfh's TESH.

Awesome updates, btw.

 

[looking_for_help]

Did you ever think of coming up with a different name for this? I'm just curious.

At the moment, I have to refer to it as lfh's TESH.

Yes, at the beginning I thought about that too

But the thing is that vJass expects a tesh.dll for loading. So without changing the vJass source code, the compiled dll has to be named tesh.dll anyway. So changing the name would cause many problems and confusions, thats why I chose to stick with tesh.

I personally refer to it as "new tesh" or "tesh 2.0".

Nice, I'll probably be updating to this one soon.

Awesome updates, btw.

Thx

 

[PurgeandFire]

But the thing is that vJass expects a tesh.dll for loading. So without changing the vJass source code, the compiled dll has to be named tesh.dll anyway. So changing the name would cause many problems and confusions, thats why I chose to stick with tesh.

Well, you don't have to change the vJASS source, the dll is loaded through we.conf.lua.

if exists("tesh\\tesh.dll") and getregpair("Software\\Grimoire\\","Enable TESH") ~= "off" then
	loaddll("tesh\\tesh.dll")
end

But yeah, I agree that it would be an extra step in installation that could be confusing.

 

[TriggerHappy]

TESH2 works for me.

 

[edo494]

I wasnt using this, well most likely because I didnt start we for like 2 months now, but mostly because I was too used for the old tesh, but now that I didnt work with we for like 2-3 months, I think its like cleared cache and I can download this and use it straight off

btw, great update

edit: just checked main page, lol you went so far to actually split Hero, Unit, Ability etc ids, and even with custom images(lovely ones)

 

[Bannar]

There is something within "New update available" post that looks familiar, don't you think @LFH? :"D

 

[Cokemonkey11]

Well, you don't have to change the vJASS source, the dll is loaded through we.conf.lua.

if exists("tesh\\tesh.dll") and getregpair("Software\\Grimoire\\","Enable TESH") ~= "off" then
	loaddll("tesh\\tesh.dll")
end

But yeah, I agree that it would be an extra step in installation that could be confusing.

I think it would be better if the JNGP package guys (moyack) would just include the new TESH since it will soon cover all the features of the old one, with only improvements. In other words, there will be no reason to use the old one.

LFH, can you add the vertical bar?

http://superuser.com/questions/414209/notepad-80-character-line-marker

And it's a lot more work, but a script outline would be really nice

http://i.imgur.com/6Bfd6On.png

Good work as usual, will download the latest update tonight if I remember

 

[looking_for_help]

btw, great update

edit: just checked main page, lol you went so far to actually split Hero, Unit, Ability etc ids, and even with custom images(lovely ones)

Thx

There is something within "New update available" post that looks familiar, don't you think @LFH? :"D

Yes It was the only code with template parameters in my test map (I actually wrote that code in parallel while testing the new template highlighting ).

LFH, can you add the vertical bar?

Hm, I don't know if Scintilla supports this, but I will investigate that. If so, it shouldn't be a problem to add this.

And it's a lot more work, but a script outline would be really nice

For now, this is unfortunatly out of scope because it would require a dynamic parser... I plan to do this, but it will not happen in near future.

Thanks for the feedback and suggestions.

 

[GhostWolf]

http://www.scintilla.org/ScintillaDoc.html#LongLines

 

[looking_for_help]

http://www.scintilla.org/ScintillaDoc.html#LongLines

Ok
Request accepted then.

 

[Zwiebelchen]

So, any update on when the function list will be implemented? I'm so looking forward to this... when the function list is done, all things the old tesh could do are supported by this aswell and I can finally upgrade. For now, only the missing function list is keeping me from updating.

 

[Glowackos]

Amazing stuff man!

The speed is great! Still takes a second or two when i edit this one 40000 line trigger i have (yes there is a valid reason for it being that long), but nevertheless it's much faster than the old tesh. :3

I'm definitely in favour of adding an option to hide the autocomplete menu if the current phrase is accepted as already complete. In this option, if user continues typing without a space, you can re-open autocomplete.
For example,
T -> opens autocomplete
rigge -> autocomplete still open
r -> closes autocomplete
A -> reopens autocomplete

Some further suggestions:
Perhaps consider backspace for reopening autocomplete.
For example,
U -> autocomplete opens
ni -> still open
x -> autocomplete closes as there is no phrase starting with 'Unix' in the library
backspace -> re-opens the autocomplete for 'Uni' prefix.

And what about auto-indenting?
If user tries to go to a new line after typing loop/then or a struct/library/scope/function/etc header, it tabs them in (would require some small parsing for everything other than 'loop' and 'than' ofc, but if you get to there, would be a cool feature).
also unindenting -> if user types endif/endfunction/etc, check its indent level and bring it back a tab if necessary. Might be useful in teaching casual/lazy coders how their code is supposed to look.

It's good that 'Load Template' can be undone with ctrl+z, else that could become a little frigthening. Maybe add a confirmation dialogue nonetheless if it detects that the text in the trigger is not the standard wc3 template after converting to custom text? Or better yet, if user converts to custom text, have it automatically replace the wc3 template with your own (if possible)? Then you could omit the load template button altogether.

I've also noticed that ctrl+z still works (to some degree) after switching to another trigger and then switching back again. Is this your doing? If so, it's nice, but I managed to get it to freeze worldedit by switching back and forth and control-zedding a bit aggressively..

'Fold All' text on button -> replace with 'Unfold All' when clicked or when anything in the trigger has already been folded. :3

Tesh.ini? For setting colourschemes etc? Though I guess you plan on adding this when you finish the options dialog.

Can't wait for dynamic user-defined function/variable autocompletion! Would be a really useful addition for my project's poiposes.

Again, great stuff!

Glow

e: oh and do you have autocompletion for lightnings too? There's a finite list of lightning strings, so may as well.

 

[Zwiebelchen]

Just a small side-note on auto-indenting:
I think it should not forcibly auto-indend your code. It should rather 'recommend' an indentation. Which means if+enter will indent the cursor by one tab on the next line, but I can still manually remove the indentation with backspace if I want it. Same goes for ends.

This is important, as for certain things you might want a customized indentation (f.ex. heavy if-nesting which will limit the workspace with a strict 1 tab indendation policy - in such cases, a 1-2 space indendation is better).

 

[looking_for_help]

So, any update on when the function list will be implemented? I'm so looking forward to this... when the function list is done, all things the old tesh could do are supported by this aswell and I can finally upgrade. For now, only the missing function list is keeping me from updating.

I am confident that the next update will bring back the function list. I guess it will take 1-2 weeks, but I can't promise anything.

Amazing stuff man!

The speed is great! Still takes a second or two when i edit this one 40000 line trigger i have (yes there is a valid reason for it being that long), but nevertheless it's much faster than the old tesh. :3

Thx
Yes, I spent really a lot time to figure out more efficient ways than the old tesh to communicate with the trigger editor but it was worth it.

I'm definitely in favour of adding an option to hide the autocomplete menu if the current phrase is accepted as already complete.

This will be added as optional once the options dialog is done.

Tesh.ini? For setting colourschemes etc?

Same here.

Perhaps consider backspace for reopening autocomplete.

Hm, I might add this optionally too. For me its too "agressive" as a default behavior but technically it shouldn't be a problem to add this.

And what about auto-indenting?

Will come, but not with the next update.

'Fold All' text on button -> replace with 'Unfold All' when clicked or when anything in the trigger has already been folded.

Thats not so easy unfortunatly as users can also manually unfold everything... I need to figure out first an efficient way to do this, but for now it has low priority.

oh and do you have autocompletion for lightnings too? There's a finite list of lightning strings, so may as well.

Thats a good suggestion, maybe you have a link to a list of those keywords?

If so, it's nice, but I managed to get it to freeze worldedit by switching back and forth and control-zedding a bit aggressively..

What you mean with freeze? A lag? Or a crash? If so this would be important to know and to fix.

I think it should not forcibly auto-indend your code. It should rather 'recommend' an indentation. Which means if+enter will indent the cursor by one tab on the next line, but I can still manually remove the indentation with backspace if I want it. Same goes for ends.

Everything will be optional and configurable don't worry


Thanks for the suggestions and the detailed feedback!

 

[Glowackos]

Methinks this is the full list.

Lightnings

"Chain Lightning Primary" - "CLPB"
"Chain Lightning Secondary" - "CLSB"
"Drain" - "DRAB"
"Drain Life" - "DRAL"
"Drain Mana" - "DRAM"
"Finger of Death" - "AFOD"
"Forked Lightning" - "FORK"
"Healing Wave Primary" - "HWPB"
"Healing Wave Secondary" - "HWSB"
"Lightning Attack" - "CHIM"
"Magic Leash" - "LEAS"
"Mana Burn" - "MBUR"
"Mana Flare" - "MFPB"
"Spirit Link" - "SPLK"

Source: http://www.hiveworkshop.com/forums/...279/beginners-guide-lightning-effects-220370/

NOTE: Don't forget that lightning codes are fed in with string tags (double quotes) and not the regular single quotes (in case you parse for this).

re ctrl+z freeze: yes, it froze WE and i had to kill the process. MAYBE it was just severe lag and i was impatient, but yeah. You can try reproduce it by sequentially changing text in three different triggers, and then going back through those triggers in the same order and hitting ctrl+z a few times (semi-rapidly). For me it froze on the second or third trigger when doing this. If you can't get it to freeze, let me know and I'll go back and see how I caused it again, then provide more specific steps.

 

[Ruke]

bug: sometimes the cursor goes back to the first line (happened a few times).
suggestion: shift + supr -> delete line

 

[Cokemonkey11]

I also experienced this bug a few times but forgot to report it. Sometimes while typing the cursor position gets reset to row 0, column 0.

 

[looking_for_help]

You can try reproduce it by sequentially changing text in three different triggers, and then going back through those triggers in the same order and hitting ctrl+z a few times (semi-rapidly).

Ok, I think I know now whats causing the problem. Next version will come up with completely reworked undo/redo functionality.

bug: sometimes the cursor goes back to the first line (happened a few times).

I also experienced this bug a few times but forgot to report it. Sometimes while typing the cursor position gets reset to row 0, column 0.

Hm, interesting, I never experienced that bug... Do you know some more isolating circumstances, when this happens? During normal writing, after accepting an autocomplete entry, or maybe after an undo/redo action?

Thanks for the feedback.

 

[pred1980]

sometimes the cursor goes back to the first line (happened a few times).

I have that too but only sometimes... you want to start writing something and the first char is on the correct position and the second starts on line 1

 

[looking_for_help]

New update avaiable


This update mainly addresses the function list of the trigger editor which has now officially a comeback. The new function list not only contains natives, bjs and constants but also types, native vJass methods and a full list of AI-natives. Also all the missing AI-natives were added to the autocomplete list and the vertical line is introduced with this update. All new features are displayed in the attached screenshots. Only thing missing with the function list is the attachment functionality (which was quite hidden in the old tesh), which will be implemented with one of the next updates.

Vertical line and missing AI-natives in action:

Also the lightning keywords were added to the string-specific autocomplete list:

Finally several minor bugs were fixed with this update, a full list is attached here:

Update to version 0.7
- Added the function list with natives, BJs, constants and native types as well as vJass constants/native methods and AI functions
- Fixed a bug with CTRL-SPACE that could cause a crash under rare circumstances
- Fixed a bug that made the calltip list appear when moving the mouse and holding CTRL
- Added the missing "type" keyword to the highlighter and the autocomplete list
- Added the missing "ALLIANCE_SHARED_ADVANCED_CONTROL" keyword to the highlighter
- Removed the non-existing "GetSelectedUnit" native from the autocomplete list and the highlighter
- Removed the non-existing bj_PingMinimapSound constant from the autocomplete list and the highlighter
- Special chars like ü are now transfered correctly to the Wc3 Editor
- Added lighning keywords to the string autocomplete list
- Fixed calltipping for multiple braces like BJDebugMsg(("test")) or BJDebugMsg(I2S(2 * (5 + 1)))
- Calltips and Autocomplete list are now disabled/re-enabled correctly when using undo/redo
- Added the vertical line to the trigger editor
- Fixed a bug that could open the calltip list on mouse move
- Fixed a bug that CTRL-Space could open the autocomplete list although the editor didn't have the focus
- Fixed a very minor redrawing bug that could occur when starting for the first time
- The currently selected word is now automatically entered in the Search/Replace edit box when opening it
- Fixed the item-order in the Search/Replace dialog for manual tabbing

 

[Cokemonkey11]

Excellent, I'll install it right now and let you know of any issues.

Is the bug with the cursor moving to 0,0 fixed as well?

I noticed if I type a line:

local integer q = '

Then alt tab in to the object editor, then press cntrl+d to see the raw codes, then alt-tab back to the trigger editor and finish the line:

local integer q = 'hfoo'

The autocomplete will pop up on typing the first h, which will then cause the cursor to jump to 0,0. This was easily reproducible. Not sure if this was the only cause for the cursor to move, though.

 

[moyackx]

Hmmm, so it has the almost all that it's needed to make it productive, then I think I'll implement this mod into JNGP from this version.

 

[looking_for_help]

The autocomplete will pop up on typing the first h, which will then cause the cursor to jump to 0,0. This was easily reproducible. Not sure if this was the only cause for the cursor to move, though.

Hm, I wasn't able to reproduce the behavior with the latest version, so I hope this is fixed now. But thanks for the info, I will investigate this further.

Hmmm, so it has the almost all that it's needed to make it productive, then I think I'll implement this mod into JNGP from this version.

Nice

The only thing missing now is actually the options dialog to configure colors and autocomplete behavior and so on, so yes I think this is now really in a usable state also for beginners.

 

[pred1980]

Downloaded... Integrated... and now testing!!! I find bugs

 

[looking_for_help]

Downloaded... Integrated... and now testing!!! I find bugs

We will see

 

[Wrda]

Wow, this really looks like an amazing TESH.
I have just 1 question: where is the place of "custom" functions?
I will implement this when you finish it for once and for all since Im patient, good luck and nice improvements!

 

[looking_for_help]

Wow, this really looks like an amazing TESH.

Thx

I have just 1 question: where is the place of "custom" functions?

You mean in the function list? Not there because it doesn't make sense to list custom functions in the function list. It is planned after this tesh reaches gold status that a dynamic parser is implemented that automatically adds user functions.

Then, of course, CTRL-Click on a user-defined function should jump to its declaration by the user, which is inside a trigger, not inside the function list. But don't expect this soon.

I will implement this when you finish it for once and for all since Im patient, good luck and nice improvements!

Thats ok. Just keep in mind that it already has (except for customization of colors) all features of the old tesh plus many new feature, less bugs and by far better performance. And I still accept feature requests, so I guess you could also profit from trying it out

 

[Wrda]

You mean in the function list? Not there because it doesn't make sense to list custom functions in the function list. It is planned after this tesh reaches gold status that a dynamic parser is implemented that automatically adds user functions.

Then, of course, CTRL-Click on a user-defined function should jump to its declaration by the user, which is inside a trigger, not inside the function list. But don't expect this soon.

Ok nice

Thats ok. Just keep in mind that it already has (except for customization of colors) all features of the old tesh plus many new feature, less bugs and by far better performance. And I still accept feature requests, so I guess you could also profit from trying it out

I see, but as you said, it might contain bugs and etc so you know...I'm not going to update the TESH because then if I find a bug (of course i would report it here) and if it screws the jngp XD. Then I would have to download jngp again and customize it again.
Anyway keep me updated

 

[bbbb1211]

Thank you!

It's very nice!
But I want to use 2byte character in TESH.
(I'm korean, old version can use 2byte character)
And It will be better to support including custom constant or keyword(for struct and method) like custom function.

English is my second language, so please excuse any English mistakes.

 

[Cokemonkey11]

In the search/replace dialogue, The Replace With textarea does not allow me to type past a small limit.

For example, COEFF_FRICTION_DESTRUCTABLE is too long to fit.

 

[looking_for_help]

It's very nice!
But I want to use 2byte character in TESH.
(I'm korean, old version can use 2byte character)

Hm, I tried some korean chars in the old version and it doesn't seem to work... Can you post some chars you would like to be recognized?

In the search/replace dialogue, The Replace With textarea does not allow me to type past a small limit.

For example, COEFF_FRICTION_DESTRUCTABLE is too long to fit.

Fixed in new version:

Update to Version 0.7.5

This is more a hotfix because I forgot in the previous versio to include all required functions into the tesh.dll so that it required the VC++ Redistributables. However, as I fixed already many things this version comes along with a lot minor improvments.

Also I added now all missing String Keywords to the string-specific Autocomplete list, as you can see in the attached screenshot.



And here a fix-list:


- Included Version Information in both the tesh.dll and the hook.dll
- Fixed the problem that VC++ Redistributables where required to use this System
- Added localized string constants to the string-specific autocomplete list
- Added cinematic strings to the string-specific autocomplete list
- Added default ai strings to the string-specific autocomplete list
- Added sound strings to the string-specific autocomplete list
- AI-functions are now marked with /*AI*/ in the function list
- Increased the maximum length of the Search/Replace textboxes
- Numbers are now not highlighted anymore as indicators when selecting them with the mouse
- Added a newline to all natives, types and constants to the function list to make them easier copyable
- Holding CTRL-key now activates hotspots even if neither the editor nor the function list initially have the focus
- Holding CTRL while function list is opened now activates hotspots correctly
- ESC-Key now can be used to close the function list
- Enter-Key can now be used to swap checkboxes in the function list when they are focused
- Fixed typos with backslashes in the function list
- Fixed a bug that CTRL-Space sometimes didn't open the autocomplete list if no matches were found
- Fixed a bug that could cause wrong brace highlighting in the function list
- Fixed a bug that kept the autocomplete list open after hitting CTRL-A
- Fixed a bug that the function list scrolled to the right when CTRL-clicking on a keyword with a long description
- Changed the naming of native methods in the function list