Open njx opened 10 years ago
There are quite likely other issues like this in the commenting code, because in general the code reaches outside each individual selection in order to figure out what to do. There are a few different approaches I could imagine taking to fix this:
selectionsToTrack
).The latter is probably easier and straightforward, but it wouldn't catch cases where, for example, the comment code wants to do two different things that overlap for nearby selections. I would think that that latter case should only occur for pathological combinations of selections where it's not obvious what the user wants anyway.
Reviewed. Low pri to me.
@njx What about inflating the selections to cover the entire comment that they'll affect, and then coalescing selections that are overlapping? I assume the selection manipulation APIs would give us the coalescing for free in that case. (We'd want to do this on a clone of the original selections though I guess, since we want to roughly preserve the user's original selection state after the edits).
Yup, something like that might work too, but I don't remember the commenting code well enough to know if that's easier than one of the other options.
Result: Nothing happens. This is because we iterate over each selection independently, but both selections would try to generate the same edit (remove the outer block comment), and those overlapping edits get rejected by
doMultipleEdits()
.