https://bugs.kde.org/show_bug.cgi?id=479936
Bug ID: 479936
Summary: Ability to track additional state via custom state
variables
Classification: Frameworks and Libraries
Product: frameworks-syntax-highlighting
Version: unspecified
Platform: openSUSE
OS: All
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: framework
Assignee: kwrite-bugs-n...@kde.org
Reporter: e...@horse64.org
Target Milestone: ---
SUMMARY
For context-sensitive grammars, I find it can be fairly difficult to track all
necessary context (in the theoretical sense) through the actual context
constructs (the KDE syntax highlight "context" item) because there can only
ever one active at once, from what I can tell. This is severely limiting
whenever there's a more complex kind of theoretical context/state to be tracked
on multiple layers, which can be necessary sometimes.
I therefore propose that rules can set named state variables tracked by the
syntax engine, as well as have preconditions depending on them:
<keyword attribute="DeclKeyword" context="NamedItem"
String="namedcodeblockitemkeywords" state-set="expect_block = 1" />
<DetectChar attribute="OtherSymbol" context="#stay"
char="{" state-check="expect_block == 1" />
(I chose this syntax so at some point it could be extended for example to += or
-= for the set part, or >= for the check part, or whatever. I think as a start,
just = for setting and ==/!= for checking should be enough.)
My apologies if this feature already exists and I just missed it.
STEPS TO REPRODUCE
1. Encounter a situation like this: "i'm looking to write a kate syntax
highlighting ( https://invent.kde.org/frameworks/syntax-highlighting ) but i
ran into a problem: in the language i'm writing it for, `{` opens a code block
and should therefore be a folding region only if it's the first `{` to follow a
specific list of "code block keywords" that fulfills all of the following
conditions: 1. it's not nested inside any other `{` or `(` or `[` bracket pairs
opened after that code block keyword, and 2. the last non-whitespace character
before the `{` bracket it isn't part of specific negative symbol list, and 3.
it isn't before potential in-between whitespace preceded by a keyword of a
specific negative keyword list. i might have missed some corner cases but i'm
fairly sure this would basically be always correct"
2. Realize it would be way easier to track if "code block start keywords" could
enter some code block expecting state, and different "code block stop keywords"
could exit it again. Same for "code block allowing symbols" and "code block
preventing symbols", and this should be fairly quick to put together as a
result, at least outside of the nesting part.
OBSERVED RESULT
It's too complicated right now to handle many variants of state (=context in
grammars that require it) if there's more than one layer of that required.
EXPECTED
With the proposed addition, it should hopefully be fairly easy to track such
additional state.
SOFTWARE/OS VERSIONS
probably all are affected
ADDITIONAL INFORMATION
--
You are receiving this mail because:
You are watching all bug changes.
