In the merge-conflicts plugin I’m working on, I mark each side of a conflict hunk by adding CSS styles to the
.line elements of an
EditorView, which I can then style appropriately from the stylesheet. (I’m also adding a class to the root so that I can scope the styles reasonably and avoid collisions. ) Right now, I’m accomplishing this by subscribing to a callback on the
editor:display-updated event that removes, and then re-applies, all of the relevant styles, finding the line elements with
editorView.lineElementForScreenRow. I have to do this each time the callback is invoked, because
EditorView removes and re-adds
.line elements all of the time as you scroll and type, so strange things happen to the line styles if I try to only re-apply when the markers change, for example.
What I’d to see is an
EditorView API for persistently applying CSS classes to specific line numbers within an editor, like that one that’s available on the
Gutter. Looking at the
EditorView source, there’s already a class list that’s passed in to the function that’s used to construct the actual DOM elements for each line. I could see it being implemented by keeping a map of line-to-class-array (which I would anticipate being reasonably sparse?) and doing a look-up each time a line is rebuilt to see what extra classes it’s expected to have.
The major benefit here would be a performance one. By re-applying classes on every display update I’m doing a lot of unnecessary work, since the line elements I’m interested in are likely to be stable for many of them. I’ve kept the callback as lean as I could and it doesn’t seem to lag even on the somewhat-ancient MacBook Pro that I’m using for Atom work, but I could easily see this becoming a problem if too many packages try to bind there.