capnproto
capnproto copied to clipboard
capnproto
Improvements to syntax highlighting
I split this up into lots of small commits to make it easier to review. It also contains the commit from #208 since I don't know how to make pull requests depend on each other (is this even possible?).
The commit Highlight: Use default colors for keywords and types conflicts with the comment regarding not using dsKeyword and dsDataType since I don't quite understand the problem described in the comment. Does this mean that some of the hardcoded colours would be the same as the ones for keywords or types? In Kate/KDevelop this is not a problem since the colours in the syntax highlighting definition are only a default an can be overridden per language in the settings dialog:
I can also try and contribute this syntax highlighting file to upstream Kate I you don't mind that.
I tested the highlighting using this file: https://paste.kde.org/ptdamq4xz
Hmm, the problem is, Qt Creator does not appear to offer me the option to configure colors for the specific token types declared by my Cap'n Proto highlighter definition. Instead, Qt Creator seems to offer one giant, static list of things whose colors I can configure. They've included everything relevant to (Qt-flavored) C++ and (Qt-flavored) JavaScript, but I'm offered no way to configure colors for Cap'n Proto. Hence I had to declare them directly in the XML.
So while your changes seem like the right thing to do for KDevelop and the like, it effectively breaks support for Qt Creator. Maybe we need two files? Any ideas?
Looking at the content of your changes, it looks like you're trying to change the highlighter to use a more conventional token-highlighting approach. I had actually intentionally designed this highlighter to highlight contexts rather than tokens, e.g. having = <default value> be entirely blue while $annotation(...) is entirely yellow. Personally I find this highlighting style to be more useful to me but I understand if some people find it weird and confusing.
So I think this further argues for forking the file rather than changing it in-place...
Yes, that sounds like it would make sense to split it. Would it be okay if I contribute your highlighting file with my changes to the upstream Kate repository?
Well, I'm a little sad that the standard highlighting then won't be the style I like, but it's certainly better than not having it, and since I'm not volunteering to try to upstream it myself, I suppose you should go for it. :)