[PATCH] Marker symbol draw on sublines

[Mitchell]

Hi Neil,

Attached is a patch against Scintilla hg from May 25, 2025 that adds two messages to Scintilla:

- SCI_MARKERSYMBOLSETDRAWONSUBLINE(int markerSymbol, bool draw)
- SCI_MARKERSYMBOLGETDRAWONSUBLINE(int markerSymbol) -> bool

The Set call enables markers with that symbol the be drawn on sublines, just like SC_MARK_BAR. The Get call is its compliment.

It uses a std::set<MarkerSymbol> behind the scenes that contains SC_MARK_BAR by default.

I chose to use marker symbols instead of marker numbers because (1) it easily supports the existing SC_MARK_BAR and (2) enabling it for individual marker numbers seems tedious. If you disagree, I can resubmit with support for marker numbers instead.

If you prefer not to include this, that’s fine, as I can just patch my application to include SC_MARK_FULLRECT in the mask along with SC_MARK_BAR.

Feel free to change the names; they’re a bit of a mouthful!

Cheers,
Mitchell

[Neil]

Mitchell:

I chose to use marker symbols instead of marker numbers because (1) it easily supports the existing SC_MARK_BAR and (2) enabling it for individual marker numbers seems tedious. If you disagree, I can resubmit with support for marker numbers instead.

I'm a bit uncertain for now.

It does seem more coherent to me for this to be an attribute of a marker number as that allows using a marker both for just head-lines or for both head-lines and body-lines.

Further extensions might want to follow more of the FoldPart technique used for MarkerSymbol::Bar with 4 bit flags to determine if the marker is drawn for head, body, tail, and headWithTail cases.

A simpler addition would be to have a continuing (or flowing?) variant of SC_MARK_FULLRECT: SC_MARK_FULLRECT_SUBLINES. There's likely only a small set of other marker symbols that are good candidates for this because they join up: SC_MARK_BACKGROUND and SC_MARK_LEFTRECT.

Neil

[Mitchell]

Hi Neil,

I am okay with defining a few new subline-enabled markers as you suggest.

With my proposed solution, I was also thinking of handling cases where clients define pixmap markers like error or warning icons that they might want to show on all wrapped lines, but I don’t personally have a use-case for that.

Cheers,
Mitchell

[Mitchell]

>
> With my proposed solution, I was also thinking of handling cases where clients define pixmap markers like error or warning icons that they might want to show on all wrapped lines, but I don’t personally have a use-case for that.

Although, now that I think about it, that would apply to all pixmap markers, so perhaps that’s not so desirable.

Mitchell