Open fredizzimo opened 5 months ago
It just occurred to me that this might not be solvable, due to this
If UI's are supposed to take control of floating windows, then Neovim won't be able to know which underlying window to actually report the mouse position for when the topmost window is unfocusable.
So the only way I can possibly see that this could work would to extend nvim_input_mouse
to take both relative and absolute coordinates, so that screenrow
and screencol
can be reported correctly.
It would also be up to the UI, to ignore unfocusable windows, and always report the first focusable one. And to be consistent with the non-multigrid case, we also need report the window underneath when the border is clicked. But for that we need the information about them
EDIT: cliking a winbar works differently than the borders, the winbar click is reported to the window, while the border click goes to the window below when multigrid is disabled.
nvim_input_mouse
to take both relative and absolute coordinates, so thatscreenrow
andscreencol
can be reported correctly.
SGTM. Except nvim_input_mouse
doesn't have an opt
arg :(
And it doesn't really help if absolute coordinates are not mandatory :(
If this gets merged, I think UIs have enough information to decide the target window themselves
We already know if the window is focusable or not, and will furthermore be able to check for border hits to simulate the standard nvim behaviour, and then send nvim_input_mouse
to the actual target window.
Problem
getmousepos()
has several problems when multigrid is enabled.winid
of 0winid
0, but I think I saw slightly different behaviour in the test code, wherewincol
andwinrow
becomes wrong instead. But maybe I messed something up there. In neovide we get awinid
of 0 though.screenrow
andscreencol
are window relative instead of screen relativeThis causes this issue in Neovide, due to the scrollbar being unfocusable
Steps to reproduce
Run this test adapted from the regular
getmousepos
testCode
```lua describe('ui/mouse/input', function() local screen before_each(function() clear() api.nvim_set_option_value('mouse', 'a', {}) api.nvim_set_option_value('list', true, {}) -- NB: this is weird, but mostly irrelevant to the test -- So I didn't bother to change it command('set listchars=eol:$') command('setl listchars=nbsp:x') screen = Screen.new(25, 5) screen:attach() screen:set_default_attr_ids({ [0] = { bold = true, foreground = Screen.colors.Blue }, [1] = { background = Screen.colors.LightGrey }, [2] = { bold = true }, [3] = { foreground = Screen.colors.Blue, background = Screen.colors.LightGrey, bold = true, }, [4] = { reverse = true }, [5] = { bold = true, reverse = true }, [6] = { foreground = Screen.colors.Grey100, background = Screen.colors.Red }, [7] = { bold = true, foreground = Screen.colors.SeaGreen4 }, [8] = { foreground = Screen.colors.Brown }, }) command('set mousemodel=extend') feed('itestingNOTE: I'm not fully sure that everything is completely correct, there might be one or two offset errors in my adapted code, as they are hard to detect when the actual code does not work properly.
Expected behavior
The tests should pass, even when the
FIXME
parts are fixedNeovim version (nvim -v)
v0.9.5
Vim (not Nvim) behaves the same?
N/A
Operating system/version
Arch Linux
Terminal name/version
Alacritty/Neovide
$TERM environment variable
alacritty
Installation
Manually built