User to user discussion and support for UltraEdit, UEStudio, UltraCompare, and other IDM applications.

Syntax highlighting, code folding, brace matching, code indenting, and function list
13 posts Page 1 of 1
I am using UltraEdit to pre-tag my Ventura Publisher texts and I am attempting to use the UltraEdit syntax highlighting feature to make my tasks easier. I know I am using this feature in a non-standard way because Ventura tagging is not programming code at all but, obviously, I am attempting to customize the program to my needs.
I wrote a language specification (thanks to Dalibor for his template) to add to the Wordfile.txt but it's not perfect at all. I would like to emphasize (i.e., to see in a different lighter color) some pieces of text, typically paragraph tags and text attributes. So I'll explain the Ventura tagging as briefly as possible and I would be very grateful if someone could help me with the Wordfile definition.

Ventura text files start with a tag like this:
@Z_STYLE70 =
It's only to identify the tagging as a post version 7 tagging style (different to previous versions of the program). Any Ventura paragraph tag starts with "@" and ends with " = " (the spaces before and after the = are mandatory). The paragraph tag is active up to the next carriage return (DOS style).

After this tag, a new tag defines the first paragraph type. For example:
@Heading = HEADING NAME
This syntax is used also for tables. Body text doesn't require any tagging and the name of the tags labels are free, as long as they start with "@" and they finish with " = ". In this area, I attempt to emphasize the whole string, from the beginning of the line (@) to the end of the tag (=). So I am able to concentrate on the text and the tagging is less disturbing. At present (see the enclosed language definition) I am getting it via /C1 definition but, as long as the names for the paragraph labels are unlimited, my proceeding is not very practical because I have to constantly modify my language definition. If I could use Auto Brace Matching, better but not indispensable.

On the other hand, I would like to make the text attributes and other codes less visible. All start with "<" and finish with ">". They can be several lines long. For example:
<I>: Italic on.
<I*>: Italic off.
<B>: Bold on.
<W0>: Bold off.

And so small caps, base line jump, begin/end kerning, point size, line break, etc. etc.

<$F: Footnote start. It finishes with a matching ">" but, in the middle, italic, bold or other attributes can appear.

<$I: Index entry. It finishes with a matching ">".
And so cross references, equations, variables, frame anchors, hidden text, etc. etc. Auto Brace Matching is indispensable in this case.

Typically, there are many codes started by "<$" but the essential signs are, as previously stated, the left acute angle and the right acute angle.
I know it's impossible to fold those strings, I have spent a long time attempting to use Marker Characters without any success and I suspect I am not correctly defining delimiters (obviously, I'd like to see my angles empasized but not my punctuation signs). Any suggestion would be welcome.

This is my language definition:

/L14"Ventura" Case File Extensions = TXT
/Delimiters = <>@=
/Function String =
/Indent Strings =
/Unindent Strings =
/Open Brace Strings = "<" "@"
/Close Brace Strings = ">" " = "
/Open Fold Strings =
/Close Fold Strings =
/C1"Tags"
corte
BULLET
HEADING
SUBHEADING
ETC. ETC.
Z_STYLE70
Z_SEC1
/C2"Attributes"
B
I
I*
W0
/C3"Delimiters"
<
=
>
@
/C4"Operators"

End of my language definition.

Thank very much in advance.
The fact of not having received any feedback is not surprising for me. I know I am attempting to use the syntax highlighting feature in a way not standard. Anyhow, I have been spending time with my problem and, via trial and error, I have a new minimalistic version of my Ventura Publisher language definition. It's OK for my purposes but, as long as I am a new user, I am unable to understand the reasons for my relative success. This is the current version:
/L14"Ventura" No Case Block Comment On = < Block Comment Off = > Block Comment On Alt = @ Block Comment Off Alt = = EnableMLS File Extensions = TXT
/Delimiters = <>=@$
/Function String =
/Indent Strings =
/Unindent Strings =
/Open Brace Strings = "<" "@"
/Close Brace Strings = ">" " = "
/Open Fold Strings =
/Close Fold Strings =
/C1"Functions"
/C2"Variable Types"
<
>
=
@
$
/C3"Keywords"
/C4"Operators"
/C5
End of definition.
Colouring:
Comments: amber.
Alternate comments: dark green.
Strings: dark green.
Variable types: purple.
My doubt is: using that definition, index entries and part of the footnotes appear in a lighter colour (obviously, this language definition is linked to my colour choice). The ambar footnote colour switches to standard pale blue text colour when an accute angle appears in the middle of the footnote (for example, an <I>) but, fortunately, the closing > for the footnote appears in purple and so I am able to easily detect the end of the footnote. Why? It's OK but I'd like to know the reason. Any explanation would be very useful to learn more about syntax highlighting.
Regards from Galiza.
I now have had time to look into your request and here is my syntax higlighting definition:

Note: tab in the delimiters list must be replaced by a real horizontal tab character after copying the definition to the wordfile.

/L14"Ventura" Nocase Noquote DisableMLS Block Comment On = <$F Block Comment Off =  > Block Comment On Alt = <$I Block Comment Off Alt =  > File Extensions = TXT
/Delimiters = $ &tab<=>
/Function String = "%@^(*=*$^)"
/Indent Strings = ""
/Unindent Strings = ""
/Open Brace Strings = "<" "@"
/Close Brace Strings = ">" " = "
/Open Fold Strings = "@"
/Close Fold Strings = "@"
/Marker Characters = "@=<>"
/C1"Tags"
@=
/C2"Attributes"
<>

What this language definition does:

  • Nocase - the language is not case-sensitive.

  • Noquote - the language has no strings surrounded normally by single or double quotes.

  • DisableMLS - there are no multi-line strings.

  • Standard block comments are used to highlight footnotes. That works only when there is a space before matching '>' because the language definition above also contains an extra space before '>'. That is required because you have written that also attributes can exist within a footnote. You can remove that extra space in the definition, but then footnotes will always end on first '>' which could be also from an attribute.

  • Alternate block comments are used to highlight index entries. Same problem with the block comment off definition as for the footnotes. You have already seen the problems with using < and > as block comments.

    A question: Are footnotes and index entries always on a single line?

    If yes, you could use Line Comment = <$F Block Comment On Alt = <$I instead of Block Comment On = <$F Block Comment Off =  > Block Comment On Alt = <$I Block Comment Off Alt =  >. That would avoid a lot of problems.

  • The delimiters are the special characters, the space and the tab character.

  • The function string finds lines which start with @ and contain the =. So you can use the function list. If you want only the strings after the equal sign in the function list, use following:

    /Function String = "%@*=[ ^t]++^([~ ^p]*$^)"

    Very interesting is also following function string:

    /Function String = "%@*=[ ^t]++^(*$^)"

    It shows you only the string right the equal sign, or the whole line starting with @ and ending with = with or without trailing spaces, but no text on right side of the equal sign.

  • Empty indent strings are defined because there are no indent strings.

  • The brace strings are alreay well-known by you.

  • The identical open and fold strings let you use the code folding engine to fold from one line with a @ to next line with a @ (= normally from one tag to next tag).

  • 2 pair of marker characters are defined to highlight the tags and the attributes. If the list of attributes is fixed. I would suggest to define them as list of "words" instead of using marker charaters. For example:

    /Marker Characters = "@="
    /C1"Tags"
    @=
    /C2"Attributes"
    <B <I <I* <W0

  • Last color group is only for highlighting < and > in case of not highlighting a footnote or index entry to matching >, or simply a single < or > inside a text.
By the way: In HTML standard there are better "names" for what you name "tags" and "attributes" - "block elements" and "inline elements" which better explains what's the difference.
Best regards from Austria
I have been out of my city for several days and I have just seen your kind answer. I'll comment it as soon as possible. Thank you very much.
Regards from Galiza.
Mofi,
I am testing your syntax definition. Keep in mind that I would like to make the text attributes and other codes (tags and so on) less visible than body text but still editable. I am including now a brief text with heavy Ventura formatting. Please attempt to see it in UltraEdit using your suggested language definition.

Attachments

Okay, the additional space on both "Block Comment Off" are not good. And the function string is also not good for your example. Here is another variant of my first post, where I have had /C2"Attributes" wrong (corrected now).

Note: tab in the delimiters list must be replaced by a real horizontal tab character after copying the definition to the wordfile.

Version 1:
/L14"Ventura" Nocase Noquote DisableMLS Block Comment On = <$F Block Comment Off = > Block Comment On Alt = <$I Block Comment Off Alt = > File Extensions = TXT
/Delimiters = $tab< =>
/Function String = "%@^(*^)="
/Indent Strings = ""
/Unindent Strings = ""
/Open Brace Strings = "<" "@"
/Close Brace Strings = ">" " ="
/Open Fold Strings = "@"
/Close Fold Strings = "@"
/Marker Characters = "@=<>"
/C1"Tags"
@=
/C2"Attributes"
<>


Next I thought, what when using the nested comment feature of UltraEdit to highlight everything between < and > as block comment.

Version 2:
/L14"Ventura" Nocase Noquote DisableMLS Block Comment On = < Block Comment Off = > NestBlockComments File Extensions = TXT
/Delimiters = $tab< =>
/Function String = "%@^(*^)="
/Indent Strings = ""
/Unindent Strings = ""
/Open Brace Strings = "<" "@"
/Close Brace Strings = ">" " ="
/Open Fold Strings = "@"
/Close Fold Strings = "@"
/Marker Characters = "@="
/C1"Tags"
@=
/C2"< and >"
<
>


And last I thought about a variant using block comments for index entries and highlight all strings starting with <$ or with only < with a substring definition.

Version 3:
/L14"Ventura" Nocase Noquote DisableMLS Block Comment On = <$I Block Comment Off = > File Extensions = TXT
/Delimiters = tab< >
/Function String = "%@^(*^)="
/Indent Strings = ""
/Unindent Strings = ""
/Open Brace Strings = "<" "@"
/Close Brace Strings = ">" " ="
/Open Fold Strings = "@"
/Close Fold Strings = "@"
/Marker Characters = "@="
/C1"Tags"
@=
/C2"Strings with <$"
** <$
/C3"Strings with <"
** <
>


For your example I like the last one (version 3) most.
Best regards from Austria
Mofi,

I agree. Your third language definition is close to perfection. Only two quick remarks now:

1. Please view my test file with word-wrap enabled at colum 80 (it's my usual working environment). Enable MLS doesn't solve the remaining problem.
2. Code folding would be more useful to collapse index entries and footnotes, if possible, instead of tags.

26.09.2007 7:33: Obviously, I started a thread about this subject in the Ventura forum but nobody could help. I know there are Ventura users that use UltraEdit and UltraEdit is perfect for Ventura, without any doubt.

26.09.2007 12:38: I see it's impossible to use code folding to collapse index entries. So, the only remaining problem is the one you can see in word-wrapped view.
The function list is a big improvement! It's a beautiful tool to navigate the file. I am sure Ventura users will appreciate that feature. Ant the "Brace" feature lets me detect the end of a footnote without any problem!

26.09.2007 13:03: Your second language definition is better in word-wrapped mode (no problem at all) and it's OK for my purposes. Any suggestion would be welcome but I think that version can be posted in the Ventura forum.

26.09.2007 13:07: Ah! But the "brace" feature doesn't work with footnotes in your second language definition... Ughhh!

Regards from Galiza.
Which wrap mode do you use exactly: soft or hard wrap?

Wrap after column # is soft word wrap.

Wrap after column #, insert CR/LF is hard word wrap.

With the third version code folding index entries should work because it is always possible to fold block comments. But code folding works only for multiple lines. so when <I$ and next > are on the same line or > is on the next line it cannot be folded.
Best regards from Austria
Mofi,
Excuse me: I haven't seen your last message (apparently, I didn't receive the automatic notification).
Speaking about your third language definition, I was referring to soft word-wrap, the only one I use. When a "See", "See also" or index entry is word-wrapped and the "<" and ">" are in different soft lines, the colouring disappears.
Anyhow, now I am using your second language definition and it's very good. The problem with "bracing" in footnotes is a minor drawback. If it's possible to fix the word-wrapping problem in your third definition, OK; otherwise, I'll keep on using the second one and I'll post it in the Ventura forum.
Excuse me if I am unable to give you more feedback in a few days because I'm going to be away. I'll be back next thursday.
Regards from Galiza and thank you very much again.
Substring definitions like ** < highlight per definition all strings starting with a < to first delimiter character according to the list of delimiters. Per definition also line breaks are always delimiters. But a soft-wrap is not a line break and therefore UltraEdit should highlight a soft-wrapped <blah;blah,blah> too.

In my point of view this is also a bug of UltraEdit. Well, normally words are short and do not span over multiple soft-wrapped lines. I think, this is the reason why nobody has ever detected this problem before. I will report this to IDM too. Maybe it will be fixed in a future version.

IDM support has confirmed this problem and it was forwarded to the developers.

Match Brace problem with second language definition where < and > are also the strings for block comment on/off can be easily solved as IDM support told me. At Advanced - Configuration - Editor Display - Syntax Highlighting enable setting Brace Match In Comments. Then Match Brace always works on < and > although they are start and end of block comments.
Best regards from Austria
Mofi,
After enabling "Brace Match In Comments", no more problem even with long footnotes. The "Brace" feature works exactly as expected. As long as a new version doesn't solve the bug in soft word-wrapping, your second version is my language definition of choice for Ventura Publisher.
Thank you very much again!
Regards from Galiza.
Problem solved in the last release UE v13.20a (december 2007)! Congratulations to the developers! The Ventura syntax is now fully functional.
The wrong behavior on highlighting a substring which spans over 2 or more soft-wrapped lines is fixed with UE v23.10.0.1 and UES v16.10.0.1.
Best regards from Austria
13 posts Page 1 of 1