Brace Matching Problem

[pwdiener]

I'm trying to use brace matching with the M4 macro language. It works sporadically, probably due to the odd quoting used by M4. For example, in this line (actually 2 lines):

define(`procdivarglist', `ifelse(`$#', `0', , `$#', `1', ``$1'', ``$1'
procdivarglist(shift($@))')')dnl


doing a BraceMatchEx on the first open parenthesis correctly jumps to the last close parenthesis. However, doing a BraceMatchEx on the second open parenthesis jumps to the same place instead of the next-to-last close paren. The statement above is legal M4.

Bill Diener

[jussij]

This is working as designed.

The second brace character code `ifelse(` is wrapped inside a string quotes.

The brace matching code is written to ignore any brace character found inside a string

Cheers Jussi

[pwdiener]

M4 has the ability to change the quoting characters. I've changed them to [ and ], respectively, since COBOL doesn't use those characters. This makes the matching work fine.

[pwdiener]

When did the capability to color brace matching become available? This works perfectly for what I want to do w/ M4 and does it automatically when I position on the paren or brace. Once I changed the quoting chars to brackets, this works great. Awesome!

Bill

[jussij]

When did the capability to color brace matching become available?

Zeus for Windows Version 3.97c

Glad you like it

Jussi

[AlanStewart]

Just tried in in 3.97c. Wahoo!! I love it!

[autocart]

This is working as designed.
...
The brace matching code is written to ignore any brace character found inside a string

Bad news. If it would honor only the string characters defined in the properties of the current syntax (tab "Keywords") then it would be cool and make sense. But having this as a general rule is bad. I am writing code in Autolisp. Braces and single quotes are used there all the time and the single quotes are not considered to be defining a string nor a character. (They have a different purpose.) Now this issue messes up my brace matching which is also essential in that language. Without a solution to this I can not consider this editor an option anymore, which is sad because the rest is pretty good.

Do you have an idea for a solution?

Regards, Stephan

[jussij]

If it would honor only the string characters defined in the properties of the current syntax (tab "Keywords") then it would be cool and make sense.

Well that definitely is a bug

Do you have an idea for a solution?

I will look to fix this so that the brace matching code honours the string settings of the document

If you are interested in doing some beta testing on this issue please let me know.

Cheers Jussi

[jussij]

This issue should now be fixed in the latest version found here:

http://www.zeusedit.com/zforum/viewforum.php?f=6

Cheers Jussi

[autocart]

seems to work, thx