Marker merging and deletion

70 views
Skip to first unread message

Mike Lischke

unread,
Jan 18, 2017, 11:30:26 AM1/18/17
to scintilla...@googlegroups.com
Hi Neil,

I'm a bit puzzled by the marker implementation in Scintilla and would like to have a little discussion about that. The background is that I keep a separate list of all markers for quick intersections to find those that require changes (and there can be many in a document). So I have track all marker movements and deletions.

1) Markers for deleted lines are automatically combined, which is surprising. Why would you want to keep the markers of a non-existing line? Unfortunately, this feature cannot be switched off, so you have to go extra rounds (maybe remove all markers and readd those you want to keep).

2) Markers are unconditionally combined, hence you easily can get the same marker multiple times. This not only additional work for drawing, it makes it difficult to remove a specific marker type. Looks like I have now to cycle and query a line until it says no marker of that type left (which also requires potentially many extra rounds to Scintilla).

If we had a way to switch merging off these problems would disappear immediately.

Regards,

Mike
--
www.soft-gems.net

Lex Trotman

unread,
Jan 18, 2017, 7:01:25 PM1/18/17
to scintilla...@googlegroups.com
On 19 January 2017 at 02:30, 'Mike Lischke' via scintilla-interest
<scintilla...@googlegroups.com> wrote:
> Hi Neil,
>
> I'm a bit puzzled by the marker implementation in Scintilla and would like to have a little discussion about that. The background is that I keep a separate list of all markers for quick intersections to find those that require changes (and there can be many in a document). So I have track all marker movements and deletions.
>
> 1) Markers for deleted lines are automatically combined, which is surprising. Why would you want to keep the markers of a non-existing line?

This is the correct behaviour for markers used for debugger
breakpoints for example.

> Unfortunately, this feature cannot be switched off, so you have to go extra rounds (maybe remove all markers and readd those you want to keep).
>
> 2) Markers are unconditionally combined, hence you easily can get the same marker multiple times. This not only additional work for drawing, it makes it difficult to remove a specific marker type. Looks like I have now to cycle and query a line until it says no marker of that type left (which also requires potentially many extra rounds to Scintilla).
>
> If we had a way to switch merging off these problems would disappear immediately.
>
> Regards,
>
> Mike
> --
> www.soft-gems.net
>
> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.
> To post to this group, send email to scintilla...@googlegroups.com.
> Visit this group at https://groups.google.com/group/scintilla-interest.
> For more options, visit https://groups.google.com/d/optout.

Mike Lischke

unread,
Jan 19, 2017, 3:11:16 AM1/19/17
to scintilla...@googlegroups.com

This is the correct behaviour for markers used for debugger
breakpoints for example.

Yes, this also came to my mind. But that's the only example I could come up with and certainly not enough to warrant that behavior as default one. When a line is gone everything is gone that belongs to it. Why only keep the markers?

Lex Trotman

unread,
Jan 19, 2017, 4:40:26 AM1/19/17
to scintilla...@googlegroups.com
On 19 January 2017 at 18:11, 'Mike Lischke' via scintilla-interest
<scintilla...@googlegroups.com> wrote:
>
> This is the correct behaviour for markers used for debugger
> breakpoints for example.
>
>
> Yes, this also came to my mind. But that's the only example I could come up
> with and certainly not enough to warrant that behavior as default one.

It may not warrant being the ONLY behaviour, but adding a different
behaviour is no reason to change the default, every existing Scintilla
user would be affected.

> When
> a line is gone everything is gone that belongs to it. Why only keep the
> markers?
>
> Mike
> --
> www.soft-gems.net
>

Neil Hodgson

unread,
Jan 19, 2017, 6:24:27 PM1/19/17
to scintilla...@googlegroups.com
Lex Trotman:

> This is the correct behaviour for markers used for debugger
> breakpoints for example.

Debuggers were the main original motivation for markers.

Mike Lischke:

> 1) Markers for deleted lines are automatically combined, which is surprising. Why would you want to keep the markers of a non-existing line? Unfortunately, this feature cannot be switched off, so you have to go extra rounds (maybe remove all markers and readd those you want to keep).

Its fairly easy for the application to respond to SC_MOD_BEFOREDELETE by deleting markers in the deletion range when desired. If the default behaviour were to delete markers then it would be more difficult for the application to implement moving/merging when desired.

Neil

Mike Lischke

unread,
Jan 20, 2017, 4:19:44 AM1/20/17
to scintilla...@googlegroups.com

>> This is the correct behaviour for markers used for debugger
>> breakpoints for example.
>
> Debuggers were the main original motivation for markers.

And I am in the same boot here :-) Only that I do not rely alone on Scintilla's handling, as this is ineffective for large files. If it would allow e.g. to replace all markers by a set of new ones in one go, things would be much easier for the application. And nobody says we should change the default. All I suggested was to add a setting to switch the merging off.

>
>> 1) Markers for deleted lines are automatically combined, which is surprising. Why would you want to keep the markers of a non-existing line? Unfortunately, this feature cannot be switched off, so you have to go extra rounds (maybe remove all markers and readd those you want to keep).
>
> Its fairly easy for the application to respond to SC_MOD_BEFOREDELETE by deleting markers in the deletion range when desired. If the default behaviour were to delete markers then it would be more difficult for the application to implement moving/merging when desired.


Most of the time, yes, and that's what I do actually. However there are edge cases, like when a marker moves to a line where none was before (on deletion). Marker message don't include move info, just a notice that a marker changed. So, they don't help either.

And Neil, you didn't consider the problem about duplicate markers I mentioned. The simple linked list move from one line to another includes no duplicates check.

Mike
--
www.soft-gems.net

Neil Hodgson

unread,
Jan 21, 2017, 5:18:14 PM1/21/17
to scintilla...@googlegroups.com
Mike Lischke:

> And I am in the same boot here :-) Only that I do not rely alone on Scintilla's handling, as this is ineffective for large files. If it would allow e.g. to replace all markers by a set of new ones in one go, things would be much easier for the application. And nobody says we should change the default. All I suggested was to add a setting to switch the merging off.

Rereading your initial post where you make a second point about the same marker multiple times which makes it appear that the first point is about dissimilar markers. So, do you want to prevent even different types of marker (such as a breakpoint and bookmark) from being on one line due to a deletion?

Additional modes can be added to marker types but the details have to be explicit. Having multiple markers of the same type is one of the reasons for marker handles and, conversely, being able to track markers with a handle is a reason for maintaining each copy of a marker on a line.

Do unmergeable markers require handles?

There are also questions about marker density. The current implementation is aimed at fairly sparse sets of markers and may not have good performance for, as an example, a history application that colours each line with a marker to indicate its age.

> Most of the time, yes, and that's what I do actually. However there are edge cases, like when a marker moves to a line where none was before (on deletion).

The edge cases will still require a choice and that choice may be different from the application requiring the application to implement the alternate.

> Marker message don't include move info, just a notice that a marker changed. So, they don't help either.
>
> And Neil, you didn't consider the problem about duplicate markers I mentioned. The simple linked list move from one line to another includes no duplicates check.

What do you mean by a duplicate here? One handle should not be used on multiple lines.

Neil

Mike Lischke

unread,
Jan 22, 2017, 3:05:25 AM1/22/17
to scintilla...@googlegroups.com
Hey Neil,

>> And I am in the same boot here :-) Only that I do not rely alone on Scintilla's handling, as this is ineffective for large files. If it would allow e.g. to replace all markers by a set of new ones in one go, things would be much easier for the application. And nobody says we should change the default. All I suggested was to add a setting to switch the merging off.
>
> Rereading your initial post where you make a second point about the same marker multiple times which makes it appear that the first point is about dissimilar markers. So, do you want to prevent even different types of marker (such as a breakpoint and bookmark) from being on one line due to a deletion?

No, different marker types are fine. I used for instance one to indicate a valid statement and another for a syntax error at the same time. This discussion is really only about multiple markers of the same type. Say you have 2 error markers on line 1 and 2 and you delete line 1. I would expect that the error marker of line one disappears automatically. But no, Scintilla merges both and the new line 1 now has 2 error markers. So I cannot even remove the error marker easily with a simple API call, but have to iterate and check the marker set and remove error markers until Scintilla reports there aren't more. That is a weird implementation and surprises the user (and is not documented). All that is only caused by that automatic merge and I really have a hard time to understand why this is the default. I see also advantages in some situations, but these are special cases and should be switch on by demand.

>
> Additional modes can be added to marker types but the details have to be explicit. Having multiple markers of the same type is one of the reasons for marker handles and, conversely, being able to track markers with a handle is a reason for maintaining each copy of a marker on a line.

I haven't used marker handles yet. Most Scintilla marker APIs work with lines and marker numbers (and sets), which is enough for me.

>
> There are also questions about marker density. The current implementation is aimed at fairly sparse sets of markers and may not have good performance for, as an example, a history application that colours each line with a marker to indicate its age.

Yes, this is why I have my own marker tracking implementation, which allows for simple intersections of the existing set and the new set of markers and only manipulate those that change (e.g. after a syntax check run). This works very nicely, but has the additional burden that I have to track automatic marker handling in Scintilla. The SC_MOD_CHANGEMARKER notification isn't terribly helpful with this task, because of the limited information it carries.

The current marker implementation via a linked list could certainly be improved (e.g. via an ordered set) which would handle duplicates automatically. Though you would no longer have marker handles (and we all know once something is introduced, there is little chance that it gets removed).

>> And Neil, you didn't consider the problem about duplicate markers I mentioned. The simple linked list move from one line to another includes no duplicates check.
>
> What do you mean by a duplicate here? One handle should not be used on multiple lines.


Not duplicate handles, but duplicate markers of the same type, as explained above.

Mike
--
www.soft-gems.net

Reply all
Reply to author
Forward
0 new messages