Fix font initialization pulling in extra metadata by ychin · Pull Request #957

Fix font initialization pulling in extra metadata by ychin · Pull Request #957 · macvim-dev/macvim

Recent fix to font initialization (macvim-dev#927) seems to have caused issues
with other fonts. Keep the fix but revert to the old way of font
initialization by manually creating a new one with point size to not use
the other aspects of the font to keep the behavior consistent with
previous behavior

Fix macvim-dev#928

ychin deleted the fix-font-initialization branch

October 16, 2019 15:28

ychin added a commit to ychin/macvim that referenced this pull request

Dec 26, 2020

Recent change to stateful renderer (macvim-dev#858) has inadvertantly changed how
MacVim handles line spacing. Previously, MacVim intentionally ignores
the line spacing of a font and creates a new dummy font that essentially
has line spacing of 1, but the new code uses the font as is. This means
font with non-standard line spacing (e.g. Input Mono) will look
different. This is technically the correct way to handle fonts but is
different from how MacVim has worked for years.

Also, see last time this regression (where MacVim didn't discard line
spacing) happened in macvim-dev#928 / macvim-dev#949 which was fixed in macvim-dev#957. Also see macvim-dev#977
where the bug was filed the other way requesting for using the font's
line spacing instead of discarding it.

This commit re-introduces the behavior to discard line spacing, but only
provides it as an option (can be set in the preference pane), while
defaulting to using the line spacing as that seems more correct.

Note that from a casual survey of other terminals and editors, this
behavior is quite inconsistent. Xcode does use the font's line spacing,
and was partially the motivation of switching to that as a default.

Close macvim-dev#1152.

ychin mentioned this pull request

Dec 26, 2020