Vimr: Setting linespace and font from init.vim

[robertgzr]

In Vimr you currently can't do:

set guifont=Iosevka:h12
set linespace=2

or use :GuiFont and :GuiLinespace to do the same from init.vim

It would be nice to have these to be able to change how vimr looks when calling something like Goyo

[clason]

Or, like for neovim-qt, in ginit.vim (sorry to keep on about this...)

[robertgzr]

@clason I solved the ginit.vim thing by just doing:

if has('gui_vimr')
  source ginit.vim
ending

But yeah it would be nice to have the same behavior across GUIs

[qvacua]

I'm not quite sure about this. Yes, (Neo)Vim and its GUIs (used to) use gvimrc (or ginit). However, until now I've been following the principal that GUI related settings should be done in the GUI. I see following issues with a config file for GUI options:

• There will be two places to set things: config file and the preferences window.
• Where do we stop? Should every GUI-releated option configurable in the config file?
• Currently we can change the structure/content of the preferences as we like (as long as we convert the user defaults plist file accordingly). This won't be either impossible or very hard to achieve once we allow for a config file...

In my opinion a better approach would be to be able to import and export GUI-related settings like Jetbrains IDEs do. This way you could sync settings across multiple devices for example...

[clason]

For me, the point is consistency across GUIs: I work on both macOS (vimR) and Linux (neovim-qt/gonvim) and would like to have a common configuration as far as it makes sense (for example, I set number and relativenumber in the GUI but not the TUI for performance reasons). Cross-platform availability and consistency is one of the major advantages of vim for me.

So I'd appreciate the possibility of setting neovim options via ginit.vim. (I should stress that neovim-qt does not have any equivalent to gui_running, so the only way to set GUI-related options is via ginit.vim.)

On the other hand, I see the point that VimR specific options (preview panes, file browsers) are best handled in a different way, e.g., via preference panes.

(GuiFont et al. is a bit of an edge case; there are arguments in favor of both approaches. In particular, equalraf's neovim-gui-shim seems to have become a sort of standard for controlling neovim GUIs.)

[ELLIOTTCABLE]

The problem, @clason, is that VimR-specific options can become not-VimR-specific options — that viewpoint is very forwards-incompatible!

I think I'm, to my own shock, actually with @qvacua, here. As much as I want open-standards and simple, textual configuration, the way I see it …

1. a textual gvimrc won't be done ‘right’ if it's not VimL,
2. VimL can't be reliably generated / parsed / modified / replaced via a GUI,
3. thus, if we want a GUI configuration interface, we shouldn't use a textual one at all.

I do see one, rather sub-par, way around this: treat VimL / textual configuration as a ‘default’-source for the GUI configuration. (i.e. if you set FooBar to true in your old-school configuration, then VimR could behave according to that, and display that setting in the GUI — but if you change it in the GUI, that change is VimR-specific, and now overrides the ‘default’ written in your config) … but to be honest, that feels rather unintuitive, and is likely to just confuse users.

Just my 2¢. (=

[clason]

@ELLIOTTCABLE I see I should have been more explicit: All I'm asking is that vimR reads ginit.vim in addition to init.vim and treats it exactly the same way -- I'm not asking for vimR to parse it in any way, just to pass its contents to the embedded nvim instance.

(After all, nobody is stopping me currently from setting GuiFont in init.vim, and nobody is currently expecting that to change the font.)

[ELLIOTTCABLE]

Based on #564 (and having had learned a substantial amount of VimL since my last comment), my opinion on this has completely slewed the opposite direction.

My argument above still holds (that GUI and textual configuration are incompatible), but I no longer consider textual configuration even remotely optional. This is Vim! Click through to the mentioned Issue — how the hell are we gonna build a remotely-robust GUI interface for all the possible ways one might want to integrate the Files pane with various Vim options, commands, plugins, not to mention the other direction (integrating your own mappings and plugins to invoke it)!

Maintaining such a GUI would be a nightmare. I strongly believe GUI configuration should be entirely abandoned, and the old Sublime approach should be taken: ⌘, should open ginit.vim in a split-view, more like :help than anything else. ¯\_(ツ)_/¯

(That said, I'm still really curious to hear what others think.)

[pathologicalhandwaving]

Look you guys need to take a step back you. You need to figure out which benefits of a gui (vs terminal vim) are you wishing/willing to develop. GUIs have a place, and they should have their own config because they will be used and can do different things.

In my opinion that config should attempt to be as compatible as it can be with core VimL in so much as you are able (not willing) to support.

"Where does it stop?"
Well decide where you want it to go first then you'll know the answer.

Its about that time when you need to think about how long you want to support this application, and who will take over (if) it continues after you've moved on.

If you can't think about that, then stick as close as you can with cannonical vimL.

If you can make a long term plan then you need to think about what you want to do differently, without kidding yourself about uniqueness.

You need to think about why vim has been so good for so long. If you work on a project with vim in the name, don't fail to read the manual or understand the paradigms.

A gui isnt a replacement, its a supplemental (similar) working environment which allows you to easily work on things that are irritating to configure in terminal, such as latex live preview, or other such infuriating crap.

[qvacua]

If I understand it correctly, neovim is implementing options for GUI settings like font and size (neovim/neovim#7520). When that feature is in a release, then it'll be not that hard to integrate it in VimR.

[ELLIOTTCABLE]

Still curious where this is headed! Looks like the referenced Neovim PR is merged; and there's a few related commits over here. Does this imply you're working on support for these in the rendering frontend?

[qvacua]

I will implement setting simple preferences, e.g. the font, via ~/.config/nvim/ginit.vim as next. I think using things from #649, it will be not that much work.

[qvacua]

Using the latest snapshot you can set the font + size and the linespacing via ~/.config/nvim/ginit.vim:

VimRSetFontAndSize "SOME_FONT", 13
VimRSetLinespacing 1.0

The font size must be an integer and the linespacing a float. A side-effect of doing this is that the Neovim's start screen is not displayed anymore.

[ELLIOTTCABLE]

Worth noting where the string "SOME_FONT" comes from. Is that the ‘PostScript Name?’

[xentek]

Worth noting where the string "SOME_FONT" comes from. Is that the ‘PostScript Name?’

Yes, it seems it is using the PostScript Name of the fonts.