Different fix for #3292474

Ok for the first situation, my fix #3292474 is no longer needed with your change from #3291579.
For 2nd case, IMHO, it seems more clear for the user to keep this highlighted line because the wrapping line is into the contracted bloc. But it's just my point of view :)

As you directly set tFold to undefined, I think you can also remove the block
"if (!highlightDelimiter.isCurrentBlockHighlight(lineDoc)) {"

Regarding 2nd case, the highlighting of sub lines is not the real problem here. I think it looks confusing to just partially highlight vertical line marker and IMHO only first line should be highlighted in this case. Especially in order to be consistent with the way how highest level fold header is contracted (no sub line markers are drawn on wrapped sub lines). If you look closely, you'll see that last sub line is not highlighted all the way to the end of line, since vertical line marker from the next line was drawn partially on top of it, due to changes introduced in #3292474 (marker on line 163 in screenshot is drawn partially above marker on previous line). Vertical line should not be drawn outside defined rectangle and that's the main problem here.

The "if (!highlightDelimiter.isCurrentBlockHighlight(lineDoc)) {" block should not be removed as it is the only place where HighlightDelimiter.isEnabled is being checked and I did not want to refactor source code more than needed.

I can see some validity with both choices and have no strong preference. If the tail is good (because you want an indication that the highlighted fold continues) then shouldn't there also be a tail on the first example where a top level feature is folded?

Tail should not be added when top level header is folded, as there is no tail when word wrap is disabled. It would look odd to have a tail and marker indicating contracted state. The same goes for sub level fold points, only first line of long wrapped line should be highlighted in order to be consistent.

Anyway, the main problem here is the change to VLINE drawing, which made it draw outside it's boundary and that clashes with other markers. For me, only way to to fix this is according to the patch that I provided.

If the VLINE drawing is a distinct fix then it should have its own tracker item so it can be reviewed and committed separately. This is also better for people looking through Hg history.

Since VLINE drawing was changed in #3292474 and this item mostly talks about that particular item, VLINE changes should be discussed here.

Other changes that fix header highlighting in second situation (so it's consistent with first) are added as an extra and they indeed would have been better if tracked separately, but what's done is done, no need separating now.

I attached another screenshot (taken using vanilla 2.27 version of SciLexer.dll) that clearly shows why VLINE changes must be reverted, as they cause line to be drawn out of bounds.

Handling fold sub header highlighting when line is wrapped is a different issue, which must be handled in some other way (other than drawing VLINE out of bounds).

Sorry for the delayed response, I was in professional trip without Internet access.
For the drawn out of bounds, IIRC it is easely (and only?) way to fix the problem describes into screenshot at #3292474 in case we keep tail on subline with wrap is enabled.
If you decide to remove this tail for subline, this hack is no longer needed, and mainly with the pb with vanilla.

> The "if (!highlightDelimiter.isCurrentBlockHighlight(lineDoc)) {" block
> should not be removed as it is the only place where
> HighlightDelimiter.isEnabled is being checked and I did not want to
> refactor source code more than needed.
Maybe you can remove "if (!highlightDelimiter.isCurrentBlockHighlight(lineDoc)) {" block and surround the remainder tests with "if ( HighlightDelimiter.isEnabled)". In my point of view, that seems most clear.

Removing the tail seems OK so this is committed.