Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

variable width, non-monospace fonts? #1065

Closed
m-faith opened this issue Apr 9, 2023 · 6 comments
Closed

variable width, non-monospace fonts? #1065

m-faith opened this issue Apr 9, 2023 · 6 comments

Comments

@m-faith
Copy link

m-faith commented Apr 9, 2023

Does NeoVim-QT support "normal" variable width, non-monospace fonts?

I do lots of writing in nvim and it would be so amazing relief for my eyes to have a "normal" (normal for the world of typography) font.

NeoVim itself does support this (some mistaken impressions did exist about it not being possible) though apparently it's not necessarily simple to do.

Does NeoVim-QT support this currently? If not, is it something you'd be interested to add?

Thanks in advance!

@equalsraf
Copy link
Owner

Short answer: not really.

Historically Vim assumes that fonts are fixed with - for various reasons. Visual block, the cursor and performance are the first ones that come to mind.

The best we can do right now is to enable ligatures, using the :GuiRenderLigatures 1 (can also use it from your ginit.vim file). I don't usually use it, but I would expect lower performance because we need to draw line by line.

You will also need to enable a variable width font, in our case using GuiFont! fontname:h12 to force the non monospace font.

I've tried this here using DejaVu Serif and the results were pretty terrible. The cursor/text was not visible in some cases and moving the cursor around caused the text to move around.

NeoVim itself does support this (some mistaken impressions did exist about it not being possible) though apparently it's not necessarily simple to do.

Not quite sure what you mean with this. My assumption is that this depends on the terminal and the terminal font being used. I'm not aware of terminals doing variable width fonts though. Can you share the details about a setup were this was working properly with neovim (font, terminal program)?

@m-faith
Copy link
Author

m-faith commented Apr 12, 2023

Hi, thanks for the response!

neovim/neovim#22125 (comment) NeoVim core contributor saying that it's possible to render variable-width fonts in a NeoVim GUI.

It would be sooo amazing to see a NeoVim GUI render variable-width fonts the way the Emacs GUI is capable of doing.

I wouldn't expect this to fit within your priorities... but... oh my... I would be so thrilled if it did :D

@equalsraf
Copy link
Owner

Ok, I got the gist of it from the comments. The way to enable this is to

  1. support the multigrid ui extension
  2. draw and manage our own windows, status bar and other (externalized) widgets
  3. In addition rewrite a lot of rendering code on our side (or maybe hand it to the Qt text layout)

The reason these are not supported right now is that it is a lot of work. I don't think we will get there anytime soon.

Maybe one of the other UIs already covers all the needed features? These seem to support multigrid and ext widgets, but I have not checked their rendering

I only tried the first two, but even with multigrid on and a proper font rendering still assumes monospace.

@m-faith
Copy link
Author

m-faith commented Apr 13, 2023

Thanks for the consideration! Neovide doesn't support it neovide/neovide#1757 yet, nor does fvim yatli/fvim#248. But I'll look into the others, thanks for the links.

@jgehrig
Copy link
Collaborator

jgehrig commented May 2, 2023

@m-faith

Thanks for the feature request! I've never thought about this case before.

While this is theoretically possible -- It would require significant re-writes based on the architecture we're currently using. All of our rendering logic requires characters to be placed within a uniform grid.

I don't think it is practical for us to add this feature. Hopefully another frontend can solve this for you!

Marking as closed.

@jgehrig jgehrig closed this as completed May 2, 2023
@m-faith
Copy link
Author

m-faith commented May 17, 2023

Thanks for your consideration :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants