Multigrid should not affect the functionality of screenchar.

I am afraid this is impossible. The entire point of multigrid is to break the assumptions that positions form a single monospace grid, which is the assumption that screenchar/screenstring relies on. These functions historically always have exited for testing purposes, rather than ordinary use, and we have other ways to test multigrid state (use the RPC api just like in actual use).

Modify the screenchar_spec.lua test to use multigrid and observe that it's failing.

There is no point in ever wanting to do this when multigrid_spec.lua exists.

I am afraid this is impossible. The entire point of multigrid is to break the assumptions that positions form a single monospace grid, which is the assumption that screenchar/screenstring relies on.

Would it be possible to make this optional, or even per window like the documentation suggests?

UIs can set the grid size independently of how much space the window occupies on the global layout. So the UI could use a different font size per-window. Or reserve space around the border of the window for its own elements, such as scrollbars from the UI toolkit.

By default, the grid size is handled by Nvim and set to the outer grid size (i.e. the size of the window frame in Nvim) whenever the split is created

Neovide aims to be a drop-in replacement for the terminal mode Neovim, with a few enhanchements like smooth scrolling, simple animations, true transparency, shadows and so on. And for that we need the bullet point below of multigrid, but not necessary the other points

• UIs receive updates on a separate grid for each window.

We probably want to enable custom and even variable fonts at some point, but that needs special consideration and perhaps new Neovim features, and it should never interfer with the base functionality like window navigation or break plugins. Especially variable fonts need a lot of thought, like how are the lines wrapped, the current protocol only sends the parts it thinks are visible, which makes it almost impossible to implement with the current protocol.

Running the compositor when multigrid is enabled would also allow issues like these to be resolved

• The position of floating windows is not updated when multigrid is used #24801
  • Emulating the Neovim algorithm is not trivial since we need to take anchors into account and move whole groups of windows, and perhaps even the composition order. And Neovide currently have some bugs related to that.
• getmousepos() reports wrong when using multigrid #27181
  • That one can not be solved even if a new api was added that takes the absolute position. We don't know if a winbar or floating window border is clicked, so we can't know which window if to send.
• A composition order field could be added in addition to z-index, since the z-index alone is not enough to render the windows in the correct order, we had to reverse engineer the algorithm fix: emulate Neovim layer drawing neovide/neovide#2612

These functions historically always have exited for testing purposes, rather than ordinary use, and we have other ways to test multigrid state (use the RPC api just like in actual use).

The API documentation does not specify that it's only for testing, and it's used in the wild by plugins that are broken in Neovide, for example https://github.com/luukvbaal/statuscol.nvim/blob/483b9a596dfd63d541db1aa51ee6ee9a1441c4cc/lua/statuscol.lua#L143.

I'm not a Neovim api expert, but I don't think there's a viable alternative for that functionality currently, and a plugin should not have to care about if multigrid is enabled or not, unless it's specifically written with multigrid in mind.

I think the above plugin might also be broken due to the mouse position issue, which also does not have a viable alternative when you click outside a window, like you need there. A responsive scrollbar also need to be able to track the mouse position globally, so this is not the only use case for it.

Modify the screenchar_spec.lua test to use multigrid and observe that it's failing.
There is no point in ever wanting to do this when multigrid_spec.lua exists.

Yes, you could copy paste the whole content of screenchar_spec.lua into multigrid_spec.lua, but I prefer to avoid code duplication and instead run the same test twice, once without and and once with multigrid to see that there are no regressions between the two, especially since it what's displayed on the screen is irrelevant for those tests.