UI line number about xi-mac

[takkuumi]

@cbrewster @cmyr i am a web developer. in CSS compute fonts width throw font-size*characters. i dont know any help for you.

[cmyr]

@cbrewster yea I was thinking about the corollary of this problem during the initial implementation: in a file with 10m lines, it looks weird to have a really wide gutter with a single number.

I agree with you in the general case, and I think for the time being just using gutterColumns * stringWidth("9") seems reasonable?

[raphlinus]

A simpler approach would just be to measure 9's. It seems unlikely this would be seriously wrong.

…

On May 5, 2017 9:05 AM, "Colin Rofls" ***@***.***> wrote: I don't particularly dislike this approach? Seems like a reasonable hack. Another option to consider is just baking in Inconsolata, and not letting the gutter font be changed... 🤔 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOyv7SZo2aKrvorsT3iDmOVFvWsI2yAks5r20iNgaJpZM4NDxXz> .

[cbrewster]

This happens when using a non-monospaced font.

[cmyr]

yea we don't know how to measure 'character width' in a non-monospaced font. That's a holdover from older code, though, we could definitely be doing better here, by actually measuring the string in updateGutterWidth()

[rkusa]

I am wondering if the naive solution of gutterColumns * max(stringWidth("0"), stringWidth("1"), stringWidth("2"), ..., stringWidth("9")) (i.e. find out which of the numbers from 0-9 is the widest und use that as a replacement for the current textMetrics.fontWidth) is good enough?

This does not take kerning and ligatures into account, but since they usually tighten the spacing instead of widening it (this assumption could be wrong), they might not be an issue.

Otherwise, we could calculate the actual stringWidth of the numbers and maintain a cache for the widest number per column count.

[cmyr]

I don't particularly dislike this approach? Seems like a reasonable hack. Another option to consider is just baking in Inconsolata, and not letting the gutter font be changed... 🤔

[cmyr]

Another option: when we're drawing each line number, we calculate expected drawing bounds. We could check this against the current gutter width, and if the width is inadequate we could fire a notification or otherwise indicate that the gutterview needs to be resized.

We could also just stash the max of this in the gutterview, and invalidate if the line count decreases?

[cbrewster]

Take the following example:
There is a file with 100+ lines, but we are only viewing the top 30 lines. The gutter will be the max width for 2 characters, but then as you scroll with lines 100+, the gutter would then resize to 3 characters wide. It would seem odd for the gutter to change width while scrolling.

[jansol]

Shouldn't the gutter, being fixed UI, be using the System font anyway? (San Francisco or whatever the System font happens to be) There are functions for getting that and NSFont IIRC has a method for measuring strings.

[cmyr]

@jansol this is definitely a design decision. Xcode, for instance, has a predefined gutter font (which may not be the system default?), but sublime text uses the user font.

[jansol]

Either way, this looks like the way to go. At least as long as our screens aren't going to fit 10k lines.