https://bugs.kde.org/show_bug.cgi?id=491412
Bug ID: 491412
Summary: Feature request: Indentation API based on regions
Classification: Frameworks and Libraries
Product: frameworks-ktexteditor
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: indentation
Assignee: kwrite-bugs-n...@kde.org
Reporter: jonathan.poe...@gmail.com
Target Milestone: ---
Currently, when an end of block is detected, it triggers a line-by-line
readback until an opening is found. As the character or word searched for can
be found in comments and strings, there's a syntax parsing logic syntax that
makes the whole thing rather complex. As the API for attributes is also very
limited, you can't rely on it without going character by character...
However, the syntax part is already handled by SyntaxHighlighting, which also
knows the beginning and end of the region.
With an API that allows you to navigate and retrieve region positions,
indentation can be simplified to something like:
```js
// a syntax in closing blocks are 'end'
if (document.defStyleNum(line, curColumn) === dsControlFlow) {
const kw = document.wordAt(line, curColumn);
if (kw === "end") {
const column = document.firstColumn(line);
// 'end' is the first word of the line
if (column > 0 && curColumn === column + kw.length) {
const cur = document.matchingOpeningRegion(line, column); // new API
// beginRegion found
if (cur) {
return document.firstVirtualColumn(cur.line);
}
}
}
}
```
As regions can overlap, APIs would be needed to retrieve several of them and
search, for example, for the previous unclosed opening (as in the case of line
indentations in a hash and array). Also functions to convert a region name into
an id that can then be used for the search (faster than systematically passing
a string). But we'd need to introduce a function called automatically when the
syntax changes.
Search functions would also be handy to use at attribute level (as mentioned
above, they are very limited). The only search functions that make use of them
are `document.find` / `document.rfind`, but are in fact
As regions can overlap, we also need APIs that return several of them, and
search for the previous unclosed opening, for example (as in the case of line
indentations in a hash and array). Also functions to convert a region name into
an id that can then be used for the search (faster than systematically passing
a string). But we'd need to introduce a function called automatically when the
syntax changes.
Search functions would also be handy to use at attribute level (as mentioned
above, they are very limited). The only search functions that make use of them
are `document.find` / `document.rfind`, but are actually text-centric.
--
You are receiving this mail because:
You are watching all bug changes.
