[vim/vim] An alternative to `highlight-font` (Issue #10684)

14 views

Skip to first unread message

Olivia (Zoe)

unread,

Jul 9, 2022, 1:29:10 PM7/9/22

to vim/vim, Subscribed

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.

As far as I know, it's not currently possible. There's highlight-font as mentioned in the title, but I can't seem to get it to work. The documentation mentions something about an obscure X11 font string. Back when I tried to get the option to work, I even used a generator to get the string.

My system info at the time:

Linux Mint 20.x (not sure which version was applicable back then)
(g)Vim 8.2.xxxx, gVim in particular using gtk2 (compiled with https://github.com/LunarWatcher/dotfiles/blob/fba484f3eab2f90378710613dcfec64a8a080565/Makefile#L120-L126)
Cinnamon on X11

This means there's one of two problems. Either:

highlight-font is broken, or;
highlight-font is too hard to use correctly

and I have no way to tell which is the case. Regardless of which is the case, this FR stands, and this isn't a bug report, because I don't really want highlight-font to be the only thing that works, when the need goes slightly deeper.

Describe the solution you'd like

This feature request is partly inspired/ignited by this video, which really points out something Emacs does better than Vim. Some of its arguments on Vim don't hold water (TL;DR: gVim exists and could support this, even if terminal vim can't), but in my biased opinion, it's hard to argue against the aesthetic emacs is pulling off here.

To start there, I fully understand that this likely still is technically impossible to pull off in a terminal, which is why this FR is aimed at gVim, and not terminal Vim. Maybe that changes one day if terminals do, but that's a future problem and not worth addressing right now beyond this sentence.

Problems solved

Varying fonts, but particularly varying text sizes make for some very useful visual aids. The org document used in the video primarily uses different font sizes on headers, which makes it extremely easy to notice where one section begins and another ends.

Notably:

Markup languages could have different sizes to emphasise headers
- ... and Vim users can configure Vim with custom highlight groups for certain comments as a way to make a pseudo-header in their otherwise headerless code.
Themes with a heavy focus on italic and/or bold could use italic fonts
HTML syntax plugins could derive style information about a paragraph, and render it in the applicable font.
Unofficial help document standards could enable table
... or other fancy stuff I haven't considered.

I'm not defining what should happen to inline font sizes, because I understand that has different technical challenges. Whether or not this is supported, the main "requirement" of sorts is to support lines with different font sizes. Different fonts should work inline regardless of whether font sizes do.

However, this does come with its own set of challenges from a plugin/theme developer perspective. In particular:

A syntax plugin may want to change the size of headers, but not make assumptions about the default font
Equivalently, a plugin that wants a different font for a section may not want to change the font size (provided it meets the requirements to actually change the font size, re: inline font size changes)

The suggestion

My suggestion is to introduce two more highlight options; fontname and fontsize:

fontname works exactly the way you'd expect; it's purely the name of a font, as used with guifont. It shouldn't accept any info about the font size
fontsize: mostly identical to the fontsize as supplied to guifont, but with a minor change; there should be a way to define a relative size as well, similar to how cinoptions-values is defined:
```
  					  *cinoptions-values*
The 'cinoptions' option sets how Vim performs indentation.  The value after
the option character can be one of these (N is any number):
    N	indent N spaces
    -N	indent N spaces to the left
    Ns	N times 'shiftwidth' spaces
    -Ns	N times 'shiftwidth' spaces to the left
```
I.e. to change the fontsize to 16, you'd use fontsize=16, while to use 160% of the default font's size, you'd use fontsize=1.6c, where c stands for character because I have no idea what really works here; the best I could come up with is fs, but that feels awkward. Alternatively, if it's technically easier to implement, absolute and relative fontsizes could be split into two arguments, i.e. fontsize and relfontsize, or something like that. Not really my preferred option, though.

As for the existing highlight-font, I don't have a preference for what should happen to it. In the spirit of backwards compatibility, however, I'd assume you'd want to keep it. If this is the case, it could become a way to set both fontname and fontsize at once; I'm sure there's applications for that as well, even if I can't come up with any examples while writing this FR. font setting both should also make duplicates and excess attributes boil down to order, which I vaguely remember takes precedence when dupes are defined.

Challenges

cursorcolumn; my proposal does make for questionable alignment. However, conceals do cause weirdness as well, as demonstrated by this help file with two tags:

File content:
```
12345678901
*tag* *tag*
12345678901
```
Whether or not this is acceptable to begin with is a discussion for another time; it is, however, how Vim currently works. Whether that's enough to justify font size changes, where the font size will cause a perceived offset, is up for debate.
Inline font size changes also cause weird behavior, particularly related to line sizing, and I imagine related to character positioning. While it's probably doable, it might not be worth doing as a result.
Not a proper challenge per se, but the default font size has to be stored in a way that's easily accessible by a relative fontsize
- on that note, if it's a pain to do for any reason at all, relative font sizes could be axed in favor of letting plugins sort out that themselves with explicit config variables. It's not elegant, but it does work.

Describe alternatives you've considered

The bare minimum in my book is adding fontsize. Being able to locally set a font arguably has fewer use-cases than being able to override the font size for either a region, or more importantly, specific lines.

Additional context

Quite a few editors already support this; Emacs being one, and essentially all the major word processors do as well (such as LibreOffice Writer and MS Word). Admittedly, they fall in a different category of editor, but still.

Additionally, I do want to point out that, beyond potentially explicitly storing a parsed font size, this doesn't affect guifont at all; it, its format, and its function remains identical.

I'm also not locked in on all the details; I understand there's technical concerns I don't have any understanding of at play

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Reply all

Reply to author

Forward

0 new messages