neovide
using non-monospace fonts...?
I'd love to be able to use "normal" non-monospace fonts for my diary and writing projects (all in nvim of course)... and have wondered if Neovide could allow me to do that?
https://github.com/neovide/neovide/issues/1396 sounds like it's not currently possible. Am I correct with this interpretation?
Someone there mentioned interest in implementing this font rendering capability. Is this on a roadmap?
Hi, thanks for the suggestion! As mentioned in #1396 indeed, this is currently not possible.
The core problem is that Neovim (and in turn Neovide) operates on a grid, where it assumes all cells to have the same width and height. This is important for the statusline and RTL text, for example. Non-monospaced fonts break that assumption and would make the statusline and RTL text look quite out-of-place, with naively starting the grid in the upper left corner and just putting each character after another one. Implementing a proper RTL and statusline detection could be an interesting challenge though.
Either way, if you don't mind, I'll close this issue in favor of #1396 to keep discussion at one place. :D
https://github.com/neovim/neovim/issues/22125 says that NeoVim core currently is capable of doing this.
Just posting here for the record, glad to favor #1396 to keep discussion in one place, thanks.
Just to clarify: the core problem is that Neovide (not Neovim) operates on a fixed width grid. There's no fundamental problem with GUIs drawing externalized grids whichever way they want, including with variable-width cells (and GUIs can draw their own statuslines, like Veonim).
Of course, that's not saying it's easy, or that it wouldn't surface interesting bugs in weird places. But it's important not to play the blame game here.
I apologize, I did not know that. But thank you for the clarification! The issue seems useful.
@MultisampledNight is this something you've had a chance to think about at all? I use Vim for all my writing projects (blog, books, documentation) and it would be tremendously amazing to be able to move this all to a GUI with variable-width fonts. The other issue you mentioned hasn't had any activity in a while.
Are there any open PRs related to this? Is https://github.com/neovide/neovide/pull/1181 (I see it has grid in its name but I don't know what multigrid is) relevant? https://github.com/neovide/neovide/pull/1227 sounds like "letter spacing" does not equal variable width fonts.
Does this fit into any of your current development goals/priorities?
I agree that this would be useful, variable-width fonts are cool. Though at the moment I'm not involved with Neovide development at all. Neovide is pretty much driven by contributors and a quite large set of people who can merge PRs/perform other administrative tasks, so if anyone feels like picking this up, they're free to do so, but there's no core backlog we're communicating on.
That being said, should I get more time and willpower to work on Neovide again, I'll probably also look into the variable-width situation. But atm, that's not the case.
Sidenote: Multigrid is a Neovim UI extension which basically allows UIs to "see" and render windows on their own. Neovide can decide to use it with --multigrid passed, or not (the default). Ref. https://neovide.dev/command-line-reference.html#multigrid
But it's important not to play the blame game here.
@clason I'm resurrecting this because I've also assumed variable width font rendering basically won't ever be possible until we get more support upstream for communicating shaping information back to neovim's text model.
Some example movements that I think would be problematic if we supported variable width fonts:
- j/k movements become unpredictable. If the user wants to go up a line, with an editor that supports variable width text, the backend needs to query for a given pixel position where the most correct boundary between characters would be in the above and below lines
- similarly block selections which select a rectangle of text would need to query the shaped text locations
So far we have jealously avoided supporting any non grid rendering of text for exactly these reasons. I dont think there was so much of a blame game being played here as much as just not knowing how it "should" be implemented given the tools we have from neovim's gui interface.
I'm reopening on the off chance that discussion might happen.
An approach we have so far avoided for compatibility reasons but will likely have to address soon is to take over the grid sizes from neovim. I think thats suggested in the neovim issue that we could size the grids ourselves, keep track of the space taken up by text in the grid and dynamically resize the grid as more text becomes available. Doing this would let us render variable line heights in the same window, but I dont think it solves the issue of movements between lines requiring information about the text shaping.
Wow, excited to see this reopen! Sorry I can't contribute to the discussion, but thanks for the consideration :)