- Progress Report -
- and a few unsolved issues -
The first lot of SHFs I uploaded to
http://groups.yahoo.com/group/power-pro/files
/Scripts/0_Syntax_highlighting_project/
were betas - good enough for a test run in actual use.
I'm now working on the next set of files which will be finals I hope.
I have fixed some problems in the next set already; but I won't
upload them yet until I receive some error reports from other people.
Also, I hope someone can suggest a solution to some of the problems
described below. Then I shall fix the glitches and upload the final set.
- Keywords problem -
Here, I use "keywords" in its narrow sense as the special parameters
which are different for different commands.
Problem: keywords should usually be placed in quotes
when used in the new syntax: this.that(expr,"keyword",zvar1)
Therefore they never become colored.
If possible, this group should be made an exception to the rule
that anything inside quotes is not colored.
The solution will depend on the individual editor.
Maybe an UltraEdit user can fix it for UE?
Maybe a Crimson Editor can fix it for Crimson?
Hint: RANGE1 is spare. I have used RANGE2 for keys codes in {braces}
If we can't find a solution for a particular editor
(I mean no way to create exceptions about certain words
if they are in quotes on their own)
then you might as well delete the entire Keywords group.
- Line labels -
I would like to highlight any line starting with @
the same color as script controls - but I don't want
to color occurrences of @ in the middle of a line.
The solution to this depends on the workings of each editor.
I shall explore further...
- Operators -
It is difficult to color all operators, I mean those
which are punctuation chars rather than a-z.
Even if I could succeed, it would lead to many false hits
- partly because of context; for example * is an operator
but also a wildcard in filenames and in *PartTitle.
My preference is to simply not have a group for operators
so they will not be colored. That would give us a spare color
(UltraEdit only allows 8 groups).
- User variables -
A spare color could be used for variables, which is possible
to achieve if you start every var with a "z" - then in your
editor's SHF, declare z to be a prefix.
You could use zgName zsName zlName for all your vars
as a reminder about global/static/local.
On second thoughts, if you adopt the habit of starting every
variable with z, maybe they don't really need a color - they
will be noticeable anyway.
Let's hope that Bruce does not introduce any new things
which start with a "z" - this exceptional char is potentially useful.
- Comments -
I got the difference between ; and ;; for comments
working properly in both UltraEdit and CrimsonEd.
It is a different solution for each editor.
- The issue of duplicates -
This can be fixed by either removing duplicated words from all
except one group, or by rearranging the order of groups in the SHF,
so one group will "win" and its color will be applied to any duplicate.
I prefer the latter plan, so each word list will still be complete.
For example "defaultprinter" is in Functions and Info Labels.
In this case, I would choose to put Function coloring
above Info Label coloring.
Similarly, in Help, some word pairs are given as
command.action and also appear in a plugin.service,
for example clip.copy and file.move.
I am not sure whether to favor Plugin coloring or Command
coloring for these.
Another dupe is "do". It is a Function and also a Script Control.
I shall favor its Script Control usage - to draw attention to
the difference between a line with "if(condition)" alone
vs "if(condition) do".
Another is "If", also in both Script Controls and Functions.
Of course I shall favor Script Controls for this one too.
IMHO it's important to give the Script Control words a different
color from the other so called *Script commands.
So, I shall move Script Controls to the top as group 1.
BTW all *Script commands are the only commands which do not have
a command.action format - you always leave out the word "Script".
I have put them in the Builtin Commands group as single words
(except for the special Script Control words).
*Format commands do not have a command.action format either
(for a good reason). I left them out because you cannot
use *Format in a script file; it is only for use in command lists.
Alan Martin
Attention: PowerPro's Web site has moved: http://www.ppro.org
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/power-pro/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
