Change history

[Greg Smith]

I added the Change history feature and one of my users complains that having it appear on top of other markers (break points and the like). Have I missed something here and is there already a way of putting the changes at the bottom of the pile?

I see that Markers are drawn in order of their numbers... so I guess it is up to me to arrange this?

[Neil Hodgson]

Greg Smith:

> I added the Change history feature and one of my users complains that having it appear on top of other markers (break points and the like). ...

> I see that Markers are drawn in order of their numbers... so I guess it is up to me to arrange this?

The marker numbers for change history are currently hard-coded and draw on top of most markers but below fold markers. This isn't deliberate but is just because the folder markers were allocated at the end leaving user markers at low numbers.

You could put the change markers in their own margin or in the fold margin or make them translucent.

Neil

[Neil Hodgson]

Greg Smith:

> Have I missed something here and is there already a way of putting the changes at the bottom of the pile?
> I see that Markers are drawn in order of their numbers... so I guess it is up to me to arrange this?

SC_MARKNUM_HISTORY* could be renumbered to leave a range for prioritized application markers. Make them, say, 16-19. There should also be some explanation and maybe symbols (SC_MARKNUM_APP_PRIORITY?) to help application developers.

This is however, an incompatible change that could cause some pain for projects that have already started using change history.

Neil

[Greg Smith]

Hi Neil,

I previously sent an email with several suggestions for improving the markers, but this does not seem to have mad it onto the list.

I think I suggested moving the codes (before folks started using them), but a more flexible and compatible way would be to be able to code markers as foreground/background. The code would draw the background ones first (in ascending marker order), then the foreground ones. If traversing the list twice is considered a problem I guess if no markers have a special mark it draws as currently and the list is traversed once... It would not bother me to have the change history marker numbers moved to the middle of the range, but I don't use that many user-defined markers so I would likely have nothing to move out of the way. The folding markers have never been a problem for me as I have a separate folding margin.

I also wondered about drawing the change markers in the gutter rather than in a margin...

Thanks for the suggestions re exta margins... but I already have two and more seems too many. I had considered translucent, but that doesn't feel quite right.

Greg

[Neil Hodgson]

Greg Smith:

> but a more flexible and compatible way would be to be able to code markers as foreground/background. The code would draw the background ones first (in ascending marker order), then the foreground ones.

That seems reasonable.

> If traversing the list twice is considered a problem I guess if no markers have a special mark it draws as currently and the list is traversed once...

The code may need a bit of reordering - there could be two masks for foreground and background markers on each margin and early exits when there are no bits on for one or the other.

Neil

[Neil Hodgson]

Greg Smith:

> I think I suggested moving the codes (before folks started using them), but a more flexible and compatible way would be to be able to code markers as foreground/background.

That would require more APIs and some more code but I only have limited time for working on this. Instead I might just special-case MarkerSymbol::Bar (which already has special code for the top, middle, and end of a range) and place them beneath other markers by drawing them first like this:

if (marks) {
{
int markers = marks;
for (int markBit = 0; (markBit < 32) && markers; markBit++) {
if (markers & 1) {
if (vs.markers[markBit].markType == MarkerSymbol::Bar) {
const int mask = 1 << markBit;
const bool markBefore = firstSubLine ? (model.GetMark(lineDoc - 1) & mask) : true;
const bool markAfter = lastSubLine ? (model.GetMark(lineDoc + 1) & mask) : true;
vs.markers[markBit].Draw(surface, rcMarker, vs.styles[StyleLineNumber].font.get(),
PartForBar(markBefore, markAfter), marginStyle.style);
}
}
markers >>= 1;
}
}
for (int markBit = 0; (markBit < 32) && marks; markBit++) {
if (marks & 1) {
if (vs.markers[markBit].markType != MarkerSymbol::Bar) {
LineMarker::FoldPart part = LineMarker::FoldPart::undefined;
if (marginStyle.ShowsFolding()) {
part = PartForFoldHighlight(highlightDelimiter, lineDoc, firstSubLine, headWithTail, isExpanded);
}
vs.markers[markBit].Draw(surface, rcMarker, vs.styles[StyleLineNumber].font.get(), part, marginStyle.style);
}
}
marks >>= 1;
}
}

Neil