RedBearAK
commented
2 months ago @ewh0
Is the current key mapping the expected behavior or this is specific to the keyboard that I'm currently using?
With both Kinto and Toshy the goal is always to make Linux react like macOS would react. So if you encounter anything that doesn't work in Linux the same way you are used to from macOS, we should always try to fix it if possible.
Normally people will invoke it by pressing "ctrl + r", but with Toshy I have to press "cmd + r" to make it works.
This works for me, in GNOME Terminal, and should work in all terminals that exist in the "terminals" list in the config file.
Quick question, what terminal app are you using where this doesn't work? Because the way "terminals" work with the Toshy or Kinto config is that the physical Ctrl keys become LEFT_CTRL. So pressing physical Ctrl+R should work like you expect. There's no remap that changes it to anything else, in terminals. Unless... you are in something like an embedded terminal in one of the VSCode variants, or some other GUI app, where the physical Ctrl key becomes LEFT_META (Meta/Super/Win/Cmd are all the same key code under different names). Then physical Ctrl+R will send Meta+R, so an embedded terminal won't react the same way to that physical combo.
It works from Cmd+R because the key in the physical position of the Cmd key on an Apple keyboard gets turned into RIGHT_CTRL. So a terminal that's not really being treated as a "terminal" just sees that key as a Ctrl key. You'll also find that the Cmd+C shortcut will do the SIGINT Ctrl+C thing, instead of copying text, if you're in an embedded terminal.
If this is an embedded terminal in a VSCode variant, there is an imperfect solution to get a few things like the reverse lookup shortcut working again in this Wiki article:
https://github.com/RedBearAK/toshy/wiki/Embedded-terminal-in-VSCode-and-variants
But frankly, things will always work a lot better if you use a separate terminal app, which can get treated properly as a "terminal" by the keymapper. Terminals in Linux require a number of different remaps that general apps don't need. The keymapper can't distinguish between a GUI app and an embedded terminal, and this can't really be fixed. Limitation of Linux keymappers.
It's a pity that this tool is not available on Windows.
There's a Windows version of Kinto. It works as well as it can with the minor glitches that all Windows keymappers suffer from. I didn't try to fork that part of Kinto since I don't know how to make it any better. I contributed a few things to the Kinto config file for Windows.
First of all, I'm very grateful to your efforts for making this awesome tool.
I am always appreciative that a few people can get something useful out of Toshy, despite its patchwork nature. It works surprisingly well most of the time.
First of all, I'm very grateful to your efforts for making this awesome tool. I've used kinto for long time and after the switch so far toshy is giving me an even better experience. Everything works out-of-box and is like a charm. It's a pity that this tool is not available on Windows.
So far I mainly notice one issue that seems to be counter-intuitive: Toshy seems to assign the key sequence "cmd + r" to the reverse search on terminal app. Normally people will invoke it by pressing "ctrl + r", but with Toshy I have to press "cmd + r" to make it works.
OS: Fedora 39 Keyboard: Logitech K380 (the model supports both Win/Mac)
On K380, the "ctrl" modifier key is located at the bottom left corner of the keyboard (here is an example layout https://resource.logitech.com/content/dam/logitech/en/products/keyboards/multi-keyboard-k380/gallery/k380-sand-gallery-1-us.png) . The other key (cmd for Mac/alt for Win) is located left next to the space key.
If I want to do a reverse search, I would actually need to press down "cmd/alt + r" instead of "ctrl + r". The position of "cmd/alt" on K380 is quite different from the position of "ctrl" key on the apple magic keyboard, which I often make it wrong as the long term muscle memory has already been built.
Is the current key mapping the expected behavior or this is specific to the keyboard that I'm currently using?