gcode_editor new lexer and qss updates

[jb0]

gcode_editor.py changes

• Rewrite GcodeLexer using token based parsing with regex
• Refactored some of the get/set function to make it more dynamic and versatile when changing colors or switching/disabling lexers
• Added qproperty-styleSyntaxHighlightEnabled to optionally disable the lexer/syntax highlighting from stylesheet. (Defaults to True)
• Add callback to dynamically resize the line number margin based on number of lines in the editor

qtdragon & qtdragon_hd qss changes

• Update Editor Colors and fonts for new lexer in argentinium.qss, dark_grey.qss, qtdragon_dark_grey.qss
• Disable alternite row coloring in dark_grey.qss, qtdragon_dark_grey.qss
• Remove QComboBox::item font setting, was causing issues in stylesheet editor window using dropdown selection
• Add styling missing for QToolButon in qtdragon_hd dark.qss, dark_grey.qss & metal.qss

Should be able to style each individual part of the gcode syntax, for examples:

[snowgoer540]

Nice work! I was working something similar to address comment highlighting in QtVCP.

But I discovered some odd behavior surrounding the interpreters handling of the semicolon that is not consistent with the RS274 standard. We are working on the best path forward, so we may have to wait until that is resolved to merge your request, as there may be changes to your work required.

But, I don't want to make you do things twice so until that is locked down you might have to hang tight.

[jb0]

No worries. If it's easier to merge the useful bits from this to your project and close this PR, that is fine with me, but I'm also happy to try to accommodate any changes required.

[snowgoer540]

Overall, I like what you've done; thank you for the effort.

I will note that you changed some of the color groupings, (for example Axes used to be color5 and now they are color4), but that said, enough of the other stuff changed that it may be irrelevant to try and keep it consistent. It just may cause people who use custom stylesheets to change from the default a bit of confusion (I am not sure if other screens other than QtPlasmaC even allow this).

That said, I think the changes you made make the g-code much easier to read. The number following a G code being the same color vs two different colors (as it was previous) makes it easier to read IMO. M codes are easier to read as well (IMO) 'm65p1' for example.

I don't see any special handling of '#', '%', '=', '<', '>', which were in the original code as "Assignment".
Also alpha characters inside of <> as well as '[' and ']' which were "Key" previously.

Since Chris wrote the original styling code, I am sure he will weigh in as to whether or not this is necessary, so hold off for his opinion.

(Assignment also included 'debug,' and 'msg,' inside of () - but this is the part we are working on sorting out, so disregard for now)

One thing I do think should change: IJK should not be included in the Color4 (Axes) group since they are not axes, I think they belong in Color5 (Other) group, especially because R is included in the Color5 group.

[jb0]

Thank you for the feedback. I've moved IJK from Axes to Other styling.

The current regex patterns will match and color variables such as #<variable> and [expressions] when they are parameters for axes, etc. It's a bit of a balancing act of how many different style variables do you want for syntax highlighting. It could be nice to be able to define like color0 to color20 and have EVERYTHING being able to be defined, but then it's a bit annoying to HAVE to define everything, and after a while if you go too crazy with the coloring everything differently it starts to look like rainbow puke without helping much with readability.

I know styling preferences is a matter of personal opinions, but I didn't feel like being able to color '#', '%', '=', '<', '>' operators too important and can just use the default color0. That being said it shouldn't be too hard to expand with more color variables if the need is there.

Thank you again for the feedback.

[snowgoer540]

I pushed the changes I was referring to previously.

Would you be opposed to adding highlighting to your commit for specific comment commands? They can be a new highlight color if that makes it easier (maybe orange as a default color).

The criteria are a bit weird, so I'll try and make it easy:

For the following group, they should only highlight the exact phrase below (inside the quotation marks), when they occur inside of parenthesis to make a comment, and only the LAST of any of these on a line should highlight:

1. "debug,"
2. "print,"
3. "log,"
4. "logopen,"
5. "logappend,"
6. "logclose"
7. "pyrun,"
8. "pyreload"
9. "abort,"

For example, only the italics text should highlight (and the comma):
(print, text)
(print, text) (msg, text)

The next criteria should only highlight if the line starts with a semi colon

10. "py,"
    Example (only py. should be highlighted):

;py,print(2*3)

Make sense?

As a bartering chip, I can take care of updating the docs for you later :)

[jb0]

Hi, I think I understand the requirements. I'm unsure why you would only want the LAST of these comment commands on a line to be highlighted. Wouldn't they all be executed and be useful to highlight all of them? example: (print, hello) (print, world)

My schedule is a bit volatile in the amount of time I can spend coding, but I will try to implement this soon.

Thanks

[snowgoer540]

While the interpreter has deviated in some areas regarding comments from the RS274 standard, one part of the standard that it does follow is this:
"If more than one comment appears on a line, only the last one will be used; each of the other comments will be read and its
format will be checked, but it will be ignored thereafter.".

If you try your example in a quick g-code file:
(print, hello) (print, world)
m30

You will see that only "world" outputs to the terminal.

[jb0]

I pushed an update that should cover the requirements listed above. In addition to the commands you listed, i added PROBEOPEN and PROBECLOSE as listed in G Code Overview. It only highlights the last command on a line. I used color[5] (used by "Other" group) for the highlighting since it would probably be the least used color in other syntax, and this keeps the number of color definitions semi-compatible with older stylesheets.

See screenshot for example.

[snowgoer540]

Good catch on the PROBEOPEN and PROBECLOSE.

We are 95% of the way there. The comma needs to be part of the check for certain commands, as they will be ignored by the interpreter if it is not there.

Currently print in this line would highlight:
(print test)
It should only highlight if it is:
(print, test)
Likewise py highlights, but it needs to be py,

I think changing this line:
re_comment_cmd = r"(?:(\s*(?:print|debug|msg|logopen|logappend|logclose|log|pyrun|pyreload|abort|probeopen|probeclose)|;py)(?:,|\s*)"

To this should do it:
re_comment_cmd = r"(?:(\s*(?:print,|debug,|msg,|logopen,|logappend,|logclose|log,|pyrun,|pyreload|abort,|probeopen|probeclose)|;py,)"

But I am not super familiar with the re token syntax either, or if/how this affects the other tokens.

[jb0]

Thank you. I updated it as you suggested to be more accurate with syntax for comma/no comma required for commands.

[snowgoer540]

Thank you very much! Nice work; thank you for contributing it.