lineNumbers gutter, formatNumber, and gutter width 'probe' values

I’m using a lineNumbers gutter on a codemirror that’s displaying selected lines from source files. That is, I might be displaying lines 1, 8, 10, and 132 from some file, and I would like the line numbers in the gutter to reflect these line numbers. To do this I’m passing a formatNumber in the lineNumberConfig which maps the visual line index (1-n) to the line numbers from the course file (in effectively arbitrary order). My implementation of formatNumber has a mapping from ‘visual line index’ to ‘source line number’, and it calculates its result by looking up the argument to formatNumber in that mapping.

The problem I’m running into is that lineNumberGutter’s initialSpacer function passes numbers into formatNumber which don’t correspond to actual visible lines. It uses a sort of increasing-orders-of-magnitude probe value comprising 9’s to figure out how wide the gutter should be, meaning that, at a minumum, the value 9 is passed into formatNumber at some point. Unfortunately, the mapping I’m using doesn’t always have the number 9 in it since I may not be displaying 9 or more lines of code. Furthermore, even if I do have 9 lines, there’s no guarantee that the 9th entry is any indication of how wide the gutter should be.

Is there any way to ask lineNumberGutter to behave differently? Can I configure a custom method of telling the gutter how wide it should be? I don’t see any way in the exported API to do this.

If there’s not, is there any way to tell when formatNumber is being called with a ‘probe’ value rather than an ‘real’ value? If I could do this, then I could perhaps implement some special handling to report a useful value.

If none of these approaches work, am I best off just implementing my own line number gutter?

I’d recommend using a completely custom gutter for this. This shouldn’t take too much code, and gives you the control to avoid these kinds of awkward cases.

1 Like

Ok, thanks, I’ll give that a shot.