First assumptions and final answers

It seems that it is common logic to make an assumption and follow it where it leads. At some point there can be a realization that the beginning assumption is not possible. The case in point is the XML file for kate editor that highlights nasm style code. Since ch showed up in highlighting and ch is a register I assumed it was improperly highlighting a register in words. I decided to fix it and by the time I had made test cases, it was obvious what was causing the inconsistency. abcdefh will be highlighted and that pretty much tells the whole story. The offending line in the XML file is below. It highlights HEX in the format that MASM liked to define it, where 0fadch was the same as 0xfadc. I am not sure how the REGEX makes the mistake, but I will post the new expression when defined.

<RegExpr attribute="BaseN" context="#stay" insensitive="TRUE" String="(\$[0-9]+[a-f0-9]*|[a-f0-9]+h)"/>

I am not sure how the translation from XML to kate regular expression happens , but it does not seem to be straight forward REGEX syntax, but I will solve and post it here. It stems from the fact that Microsoft MASM syntax likes #(number hex/decimal ) with an h following and it will be solved, just for the experience. It doesn't map 1:1 for REGEX, so I guess I will start with looking into kate XML to REGEX documentation.

This link at kde about kate REGEXP confirms my suspicion that "kate REGEXP" is not the same as perl or grep. So I must learn a dialect change to solve this, but I endeavor to persevere because it embiggens me.

<RegExpr attribute="BaseN" context="#stay" insensitive="TRUE" String="(([0-9]){1}[a-f0-9]*[a-f0-9]+[Hh]+)" />

I did not notice the orring symbol | in the REGEXP, and thus it didn't make sense. The expression above does generally what I want and close enough is good enough in this case since it isn't anything more than cosmetics. As they say, "Beautiful code is only one character deep".

Being that I am somewhat compulsive it is no surprise that I had to know and control to a level of detail that is binary and perfect. So here is another link for kate REGEXP and highlighting and apparently the built in rules like to highlight numbers without an ending word boundary so I deleted those and added my own that specifically highlight "decimal" code as that is an issue when coding and you switch from octal to hex to decimal without noticing. It wasn't the REGEXP that was so odd, it was other XML interacting so I am glad that is solved.

.