Update configuration.md doc to reflect reality

[kika]

#1211 (comment)

the colon is required for the parser to pick up the option

What kind of change does this PR introduce?

• Documentation

Did this PR introduce a breaking change?

• No

[ad-chaos]

I think a better recommendation would be to suggest doing

vim.o.guifont = "Source Code Pro:h14"

[last-partizan]

@ad-chaos i like your suggestion.

On the other hand, i think format { "Source Code Pro", "h14" } should be perfectly valid, without colon.

And we should fix our code to accept this.

[ad-chaos]

Hmm, in that case you should take that to neovim since they control vim.opt behaviour

[last-partizan]

impl FontOptions {
    pub fn parse(guifont_setting: &str) -> FontOptions {
        let mut font_options = FontOptions::default();

        let mut parts = guifont_setting.split(':').filter(|part| !part.is_empty());

That's our code, we just expect : to be there, but we can make that optional.

[ad-chaos]

If you run something like

lua vim.opt.guifont = {"Source Code Pro", "h14"}
se guifont?

You'll see that the way that table is parsed into Source Code Pro,h14 that is Source Code Pro and h14 are considered two different fonts. And the documentation also says that a : is used for options and an _ can be a space. That's why we do all that parsing the way we do it.

We could add our own bit of logic to check when it is an option and when it is a font, but what if someone wants to use a font named h14? We search for a font, if we don't find it then use it as an option. That's sounds a little complex and tricky though.

[kika]

Help me understand, please: vim.opt.guifont is a list of fonts and the editor tries them in sequence until it finds the font that works and then stops. The rest of the list is not used. Is that right? What happened in my case and what lead me into frustration is that I understood that this list is comprised of either one or two components - font name and optional list of options separated by :. I didn't know that vim supports a list despite being a vi/vim user since 1989 :-) My .vimrc always had guifont option of exactly one font and I didn't even read the doc on this option once until a few days ago when I decided to start life from scratch and move over to Nvim, Lua configuration and the rest of the 21st century achievements.
Now, if that is true, why when I specified the "no-antialias" option, it was applied to the font? What happened when I put the following into the init.lua: vim.opt.guifont = { "Fixedsys Excelsior", "h16:#e-alias:#h-none" } is that #e-alias was applied to the font, but h16 was not (because of the missing colon). And I was running in circles trying to figure out what's going on, until I found a discussion in the issues (mentioned in the PR) and put the colon there.
According to the logic above, :#e-alias should apply to the non-existent font h16, right?

My understanding of the documentation:

- Options
  - apply to all fonts at once.

is that "options apply to all fonts" meaning "all fonts listed in the same string through a comma". It kind of makes sense, I may have a group of fonts which bear similar characteristics (like not having antialias recommended) and I list such fonts together in one string and with the same options. But if these fonts are not present/supported I fall back to another set of fonts with another set of options. "Cross-pollination" of options doesn't make any sense to me.

Or I'm just royally misunderstand something.

Edit: font in question is https://github.com/kika/fixedsys and it requires anti-alias off to look genuinely old as I am.

[ad-chaos]

So @MultisampledNight cleared that up on discord. Fonts are a comma separated list of fallbacks followed by a colon with options that apply to all the fallbacks.

Edit:
Ok you already mentioned it, I didn't read 😅

[kika]

@ad-chaos so the behavior is "even if guifont is a list, it's treated as a single string, with all fonts from all list elements joined together with a comma and all options from all list elements joined together with a colon"? Is that correct?

If yes, super confusing I'd say. Why list then.

[ad-chaos]

well, its not a list, its a string all along. vim.opt is extra magic that can accept lua tables and convert it to the appropriate format. And that's why I suggested you use vim.o, its transparent.

[kika]

PR updated

[MultisampledNight]

Alright, thank you!