New Wordfile for AutoHotKey (AHK) 1.1.06.02

[rhapdog]

AutoHotKey 1.1.06.02 was released February 13, 2012 (2 days ago).

I have created an updated word file that will work properly with this new version (including the new commands added on February 12, 2012.)

EDIT:
I am attaching the files, just unzip it and copy the one you wish to use to your wordfile directory. You'll have to merge the included tag list into your existing tag list if you wish to use it. See UE's help section on that if you need assistance, or there may be a topic somewhere.

I stripped the syntax colors before attaching. The files should are ready to go, but you'll need to add your colors to it if you aren't using default colors of UE.

I hope this will help the community. I will email IDM a copy now that the kinks have been worked out of this, thanks to Mofi's help below.

[Mofi]

/DeLimiters = is an unknown definition for UltraEdit. I corrected it to /Delimiters =.

The regular expressions for the function strings are always executed with ignoring case and therefore I replaced [a-zA-Z] by just [a-z] and made some other small changes in the regular expressions for the function strings.

Next I loaded my macro SyntaxTools.mac and executed first the macro SortLanguage to sort the words in the file. Next I executed the macro TestForDuplicate. The result of this macro is:

Code: Select all

Sorry! Found following duplicate words:

Click -> in /C1
Click -> in /C2

Control -> in /C1
Control -> in /C5

GetKeyState -> in /C1
GetKeyState -> in /C4

Pause -> in /C1
Pause -> in /C5

Abs -> in /C2
Abs -> in /C4

ACos -> in /C2
ACos -> in /C4

Asc -> in /C2
Asc -> in /C4

ASin -> in /C2
ASin -> in /C4

ATan -> in /C2
ATan -> in /C4

Ceil -> in /C2
Ceil -> in /C4

Chr -> in /C2
Chr -> in /C4

Cos -> in /C2
Cos -> in /C4

Delete -> in /C2
Delete -> in /C5

Exp -> in /C2
Exp -> in /C4

Floor -> in /C2
Floor -> in /C4

Left -> in /C2
Left -> in /C5

Ln -> in /C2
Ln -> in /C4

Log -> in /C2
Log -> in /C4

LTrim -> in /C2
LTrim -> in /C4

Mod -> in /C2
Mod -> in /C4

Right -> in /C2
Right -> in /C5

Round -> in /C2
Round -> in /C4

RTrim -> in /C2
RTrim -> in /C4

Sin -> in /C2
Sin -> in /C4

Sqrt -> in /C2
Sqrt -> in /C4

Tab -> in /C2
Tab -> in /C5

Tan -> in /C2
Tan -> in /C4

+ -> in /C5
+ -> in /C6

So some words exist twice in two different color groups. One occurrence of those duplicate words should be deleted. But I'm not familiar with AutoHotkey and therefore don't know from which color group it would be best to delete a twice defined word. After removing the duplicates the macro SortLanguage should be executed once more to resort the words.

Last I executed macro TestForInvalid and it reported:

Code: Select all

Sorry! Found following invalid words:

{AltDown}       <- contains the delimiter:  }
{AltUp}         <- contains the delimiter:  }
{Blind}         <- contains the delimiter:  }
{Click}         <- contains the delimiter:  }
{CtrlDown}      <- contains the delimiter:  }
{CtrlUp}        <- contains the delimiter:  }
{LWinDown}      <- contains the delimiter:  }
{LWinUp}        <- contains the delimiter:  }
{Raw}           <- contains the delimiter:  }
{RWinDown}      <- contains the delimiter:  }
{RWinUp}        <- contains the delimiter:  }
{ShiftDown}     <- contains the delimiter:  }
{ShiftUp}       <- contains the delimiter:  }

To fix this I removed { and } from the list of /Delimiters =. If this is not good because { and } are needed as delimiters, they should be added again and instead this words should be edited. It would be already enough to remove } from these words because it is possible that the first character of a word in the wordfile is a delimiter character.

But if { and } are delimiters and are highlighted with /C7"Separators", it would be perhaps better to remove { and } from these words. Then it would be necessary to run TestForDuplicate and remove the duplicates. I could see that there is {AltDown} in /C2 and AltDown in /C5.

I replaced the wordfile you uploaded. But this wordfile still needs some modifications as written above.

[rhapdog]

Thank you for your help. I will work on finishing up the final "fixes" on this, hopefully today.

I got the list of words for the different groups directly from the AHK Wiki, where they list it for people to make syntax highlighting work with their editor. Apparently they had the same keywords in multiple categories for some reason I can't comprehend. I'll examine them and try to determine exactly where they should go.

The "/DeLimiters" issue, as well as anything else that was above "/C1", was a straight copy/paste from the original AHK wordfile that was on IDM's Extras page, so the error was there first. I should have paid attention to that as well. That's what I get for assuming. Especially with another person's work. I've fixed other people's code so often I should know better.

As far as the invalid words go, they were also in the original ahk file, as well as the { } being used for delimiters. Sounds like I had a bad one to start with that I was trying to update. Once we get all this fixed, that bad one needs to be replaced for sure.

I'll post again when I believe I have the issues corrected, then you can check it again. Thanks again for the assist.

EDIT: It appears that the keys such as {Enter} are the way the word is supposed to be, and not Enter. Also, the curly braces are used the same way as C and PHP, as "begin" and "end" parts of a conditional, loop, statement group, or function, so will also need to be indent and unindent IF not part of a word. That also makes them a special character when alone. Here is the kicker... the curly brace also is used to define associative arrays, as follows:

Code: Select all

Array := {KeyA: ValueA, KeyB: ValueB, ..., KeyZ: ValueZ}


I don't think all 3 methods can co-exist at once. However, I would really like the {Enter} style words to be auto-complete including the curly braces, as the braces are the harder entity to type (2 buttons to press instead of one). If I just do "Enter", then the wordfile will cause "Enter" to be suggested for automatic completion of the word, but not {Enter}. Should I package up a separate auto-complete file for this to include those and allow the highlighting to only cover what is inside the braces, with the braces receiving a separate highlight?

[rhapdog]

Lucky for me I'm beta testing UE 18. The version of UE and UES that I currently have is the ones in that very small list of ranges of versions that cannot run your syntax macros because of the bug in those versions.

I used 18 beta and was able to run the macros and I have (I believe) completed the work on the wordfile.

I created one with Nocase and one without that, so there are case sensitive and case insensitive versions. Although it is a case insensitive language, I prefer my auto-complete to be case sensitive, therefore I opt for leaving out the Nocase keyword for myself. I made sure I correctly put the [a-zA-Z] and [a-z] appropriately in the function definitions of each. I also made sure I performed the sort for each one separately.

I removed all the duplicates found. I had to make judgement calls on some of them, because some of those words act as a variable or constant in one context, and as a function call in another, each returning different results depending on how they are used. Also, the + character can be used to indicate the "Shift" key, which meant is should be going under "Keys", but it can also be an operator. Again, it depends on context. A judgement call had to be made, and I left it as an operator instead of a key. All I can say is, the parser must slow down a bit to have to take so much in context to figure out which it should mean. There must have been a more efficient way to do it, but I like taking advantage of it so I won't quibble.

Let me know if any further corrections need to be made.

[Mofi]

A-Z in /Function String 4 = "%[^t ]++^(#[a-zA-Z]+ ^)" in file ahk_case.uew could be removed because the UltraEdit regular expression searches are ALWAYS executed case insensitive even if the syntax highlighting itself is case sensitive because of missing keyword Nocase. It is not really wrong to use in a character class definition a-zA-Z, but it just makes the wordfile 3 bytes larger in comparison to using just a-z.

---

{ and } are used for block definition and array definition and therefore I agree that these 2 characters must be delimiters and syntax highlighted with /C7 in the first place.

Unfortunately this makes syntax highlighting of {Enter} and other keys together with the braces in one color impossible except the color for keys is the same as for the braces. Perhaps you move the braces to /C5. That would not be so bad because the braces define blocks and therefore why not using a different color than for the other brackets.

Also possible would be to define the keys with just opening brace like {Enter. That would result in highlighting Enter only when preceded by an opening brace.

Adding extra {Enter} does not make sense. The keys with the closing brace at the end would be ignored for syntax highlighting as well as for auto-completion and auto-correction.

Because opening brace is a word delimiter, auto-completion always ignores {Enter} as well as {Enter. If you enter { and press Ctrl+Space, UltraEdit will not only show those strings defined in the wordfile with an opening brace at the beginning, it shows all words. At least Enter is also included even when defined in the wordfile with {Enter.

And using an auto-completion file for *.ahk files containing line by line all the keys with the braces is also no help because opening brace is a word delimiter. UltraEdit ignores the opening brace on comparison with the lines in the auto-completion file.

Conclusion: Getting the keys with the braces absolutely correct highlighted and correct suggested on auto-complete would work only when the braces would not be delimiter characters. Well, if you have the braces for block opening and closing always on separate lines, highlighting of these braces would also work without defining the braces as word delimiters because the braces are then always surrounded by delimiters (spaces/tabs/line terminators). To get the braces highlighted on an array definition without defining the braces as word delimiters, it would be necessary to have left and right of the braces a space or line termination on array definition which should be possible too. So it might be an option for you to remove the braces from the delimiters list and define the keys with the braces. But for correct highlighting the keys it is then necessary that other delimiter characters are always left and right of a key string with braces in an *.ahk file.

---

What is wrong defined in both wordfiles and therefore not highlighted correct is .=

The point and the equal sign are both delimiters. The point must be defined without the equal sign in /C6 and is then of course always highlighted independent of the next character. At the moment the point of .= has the color of normal text and the equal sign has the operators color.

That's all. I could not see any further mistake or something which could be improved.

[rhapdog]

A-Z in /Function String 4 = "%[^t ]++^(#[a-zA-Z]+ ^)" in file ahk_case.uew could be removed because the UltraEdit regular expression searches are ALWAYS executed case insensitive even if the syntax highlighting itself is case sensitive because of missing keyword Nocase. It is not really wrong to use in a character class definition a-zA-Z, but it just makes the wordfile 3 bytes larger in comparison to using just a-z.

I have changed it to a-z.

Conclusion: Getting the keys with the braces absolutely correct highlighted and correct suggested on auto-complete would work only when the braces would not be delimiter characters. Well, if you have the braces for block opening and closing always on separate lines, highlighting of these braces would also work without defining the braces as word delimiters because the braces are then always surrounded by delimiters (spaces/tabs/line terminators). To get the braces highlighted on an array definition without defining the braces as word delimiters, it would be necessary to have left and right of the braces a space or line termination on array definition which should be possible too. So it might be an option for you to remove the braces from the delimiters list and define the keys with the braces. But for correct highlighting the keys it is then necessary that other delimiter characters are always left and right of a key string with braces in an *.ahk file.

Simple solution: I moved the braces from /C7 to /C5. It shouldn't cause any problems like this. It will provide a good highlighting for blocks, as well as blend in with the keys. I don't think anyone will confuse a block for a key. If they do, then they have no business being a programmer.

What is wrong defined in both wordfiles and therefore not highlighted correct is .=

The point and the equal sign are both delimiters. The point must be defined without the equal sign in /C6 and is then of course always highlighted independent of the next character. At the moment the point of .= has the color of normal text and the equal sign has the operators color.

I have removed the .= and replaced it with . which should allow the correct "highlighting", and also helps to locate the decimal place in real numbers.

---

As far as the issue goes with the braces being delimiters, so they can't be inserted by auto-complete or wordfile, this is the reason I included a "Tag List" file with the zip archive. The tag list contains those words with the braces to prevent having to type them every time. I may expand it later to include the entire set of key-presses.