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