What's the use case for a separate GUI for neovim? I remember using macvim for a few days maybe 8 years ago, but I never "got it". It felt like the benefits of having my editor in my terminal were thrown out for little return.
If neovim had a proper gui, you could move away from some of the limitations of the terminal. The biggest being using fixed width characters for drawing UI elements.
Emacs does it pretty well, one of the few things that makes me jealous of emacs as a vim user.
IIUC fixed widths is more than just a UI problem. Lots of internal code is assuming that. But maybe it works well-enough that it isn't a real issue.
I remember trying a terminal that didn't have fixed char widths and it mostly worked. The only real issue was line wrapping (as vim and the terminal would both wrap based on how long they considered the line to be). So maybe it would be possible! I would love to see solid support for variable-width fonts.
I know variable-width fonts are controversial, but I actually think they work well for coding but haven't had the chance to use them much due to Vim limitations. But especially for Markdown and similar mostly-text content they seem like a clear win.
And input limitations can be resolved by non-terminal UIs (for example like Ctrl+i and Tab being mapped to the same control character in old terminals - that one is solved by newer protocols, but the problems don't end there.)
Neovim already supports these keys as long as you are using a terminal that supports the Kitty keyboard protocol (Kitty, wezterm, alacritty, foot, ghostty)
Yes modifiers are a state, not a key. The kitty keyboard protocol does indeed send events for left and right modifier key press/releas as you can easily see for yourself by running
kitten show-key -m kitty
in a kitty terminal and pressing the left and right modifier keys.
So why are you talking about a key then??? Kitty doesn't support left/right modifiers unlike proper keybinding handling apps, the left/right presses for non-modifier keys aren't relevant
How would you bind LeftAlt-A to something different from RightAlt-A in Kitty?
There is no such thing as a left or right modifier STATE in ANY application. All applications, including kitty track only CTRL, SHIFT, ALT, ETC modifier states. left and right alt and control are key events and can be bound in any application supporting the kitty keyboard protocol as key events. If some application tracks a left and right modifier state it has to do so manually using key press and release events, the OS does not supply it any such state.
You seem to be thoroughly confused about what is a modifier and what is a key. Left and right ctrl/alt/shift are KEYS not MODIFIERS. You can track whether they are held down or up by tracking their press and release events just like for any other key.
This rigid simplistic attitude is precisely why we can't have nice keyboard things and have been stuck in the same state of bad defaults for decades
The only differentiator for a modifier state is that it... modifies! Here is a wiki common sense definition
> In computing, a modifier key is a special key (or combination) on a computer keyboard that temporarily modifies the normal action of another key when pressed together
So your limitations don't make conceptual sense, not only can you have LShift vs RShift modifier state, but also you can have an F modifier state when you hold down the F key to modify the behavior of other keys
> OS does not supply it
Unless it does?
> VK_LSHIFT VK_RSHIFT VK_LCONTROL VK_RCONTROL VK_LMENU VK_RMENU These left- and right-distinguishing constants are available to an application only through the GetKeyboardState, SetKeyboardState, GetAsyncKeyState, GetKeyState, and MapVirtualKey functions.
ROFL you are saying that kitty the program that finally broke the keyboard logjam with terminals of preventing you from having nice things!! Good luck to you.
And lets apply some common sense to your common sense, follow up on it a little. If a modifier is defined by the fact that it modifies the actions of other keys, then left and right modifer keys modify the action in exactly the same way and thus are the same modifier. Common sense indeed.
no left and right modifier state on macOS. And neither does X11/Wayland have them, though I dont have a link handy, so I will just leave you with a couple of links to the documentation for cross platform toolkits instead:
And in case the common sense didnt make it past your mental barriers, a terminal keyboard protocol has to work on all platforms not just windows.
The good lord alone knows what windows does, probably synthesizes that state based on press and release events.
I'm not saying that, it's something you've made up for your inner rofls.
> If a modifier is defined by the fact that it modifies the actions of other keys, then left and right modifer keys modify the action in exactly the same way and thus are the same modifier. Common sense indeed.
No, that's nonsense and factually wrong. Common sense is that a different modifier key is still a different modifier key even if the modification is the same. You have to do some logic twists not to make it so. Also, this is factually wrong: they don't modify the action in exactly the same way, that depends entirely on your config. In mine they act differently
> And if you want to reference windows, a platform kitty does not support, here you go:
But your overly confident overly broad statements weren't platform limited. So how are your links to the backward platforms / gui frameworks relevant? I've already acknowledged "state of bad defaults"
> a terminal keyboard protocol has to work on all platforms not just windows.
And if you turn your mental barrier off, it's pretty obvious how to make it work everywhere - you simply flag both left+right on getting the no-side flag info on a backward platform that doesnt differentiate. And only flag either left or right on a platform that does differentiate. Or differentiate it yourself by reading raw codes. So there are no good reasons to create yet another bad keyboard protocol when it works fine without blinders off
> The good lord alone knows what windows does, probably synthesizes that state based on press and release events.
Do tell me, what is the alternative magic of how Mac/Linux synthesize Shift state without press/release events?
> I'm not saying that, it's something you've made up for your inner rofls.
Says you. And as you have abundantly demonstrated, you are a moron.
>No, that's nonsense and factually wrong. Common sense is that a different modifier key is still a different modifier key even if the modification is the same. You have to do some logic twists not to make it so. Also, this is factually wrong: they don't modify the action in exactly the same way, that depends entirely on your config. In mine they act differently
ROFL more idiotic assertions.
> But your overly confident overly broad statements weren't platform limited. So how are your links to the backward platforms / gui frameworks relevant? I've already acknowledged "state of bad defaults"
Nope my perfectly confident assertions were perfectly correct and shared by every framework under the sun. Because they are right. You coming up with nonsense use cases from under your overly small sized hat doesn't change that.
> And if you turn your mental barrier off, it's pretty obvious how to make it work everywhere - you simply flag both left+right on getting the no-side flag info on a backward platform that doesnt differentiate. And only flag either left or right on a platform that does differentiate. Or differentiate it yourself by reading raw codes. So there are no good reasons to create yet another bad keyboard protocol when it works fine without blinders off
The good reason is that modifiers are state. Left and right modifier keys modify that state in exactly the same way. You WANTING them to work differently doesn't make it so. And you bloviating about how it's a bad protocol just makes you look like the moron you are, No terminal emulator developer is going to agree to implement a keyboard protocol that requires bypassing how the platform the terminal emulator runs on handles modifier keys. Because you want it to be so. What a joke. Grow up. Or actually dont, keep on ranting on internet forums about your pet demand, all the grown ups are just going to ignore you and/or laugh at you. Good bye and good luck.
> Nope my perfectly confident assertions were perfectly correct and shared by every framework under the sun.
Except for the most popular OS in the world and the frameworks that support it (including those you linked, QT has a way to query Windows and get Right Shift key state)
> You WANTING them to work differently doesn't make it so.
Except it does, and your childish trolling and insults can't change this simple FACT that they DO work differntly precisely because I WANT that and I've set it up to work like that, not all software is as narrow-minded as you are. Live with it.
Seems more likely to be something you implement with e.g. kitty/iterm/sixel escape codes than moving to a GUI app. Actually probably is something that could be implemented in neovim today. Maybe even by a plugin, not sure what control they have over stuff like that.
