Operator syntax within variable names not working

Suppose you may use the following pattern for such variable name token:
PatternValue="var\d+({WhitespaceMacro})*(\+)*({WhitespaceMacro})*(var\d+)*"
so var1 + var2 or var1+ or var1 will be recognized as a single token. You should place this token definition before operator's.

Hope I helped.

Regards,
Alexey

Hello Alexey,

The pattern you provided is not working. This is what is happening. I define the operators in the default state within an XML file. After the XML is read in, I then create a new LexicalGroup for the variable names. This is because the variables can change all the time. I then insert the variable name token group at the beginning of the lexical groups for the default state. I am only using one lexical state.

By the way, the variable names I listed in my original post don't have to have var in the name. The names can be anything, including any characters and white space. Would the Syntax Editor be able to handle this? For example, it would be perfectly feasable to have "this + is - a > variable.name" as a variable name. If I made sure that I had the right pattern for identifying the variable name token and I made sure that the lexical group for variable names came before anything else in the lexical groups for the default state, would it be possible for the weird variable names to be recognized as lexical tokens? Would I need to create a different state for variable names or a different scope?

Thanks, Brian B.

Here is a realistic example:

Customer has variable named: *var + mny-US1 6/7/07

Then the customer types the following into the editor:

*var + mny-US1 6/7/07<=2

We need the variable token to be properly highlighted. Then the operator <= would have a different highlight and the number 2 would have a different highlight.

I have been playing with the pattern format and the look ahead format and I just can't get the right combination.

Thanks, Brian B.

Brian,

It seems like your variable naming pattern is going to be far too ambiguous for a dynamic language to work. Perhaps it would be better if you wrote a programmatic lexical parser similar to our Simple language sample that was able to handle this complex parsing of variable names. This way it could also be dynamic since your code could update as needed.