-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ctrl-ArrowKeys don't work anymore #2
Comments
I’m reviewing your issues & I have to say I’ve not tested this with any keyboards besides standard US & Apple US keyboards. Non-working arrow keys or @ symbol would be completely unexpected. It could be happening on the keymap reset that I perform just before applying the keyswap keymap. Typically changes Kinto makes I would expect to follow the layout options for your given language, as a language is not specified. I am curious can you try looking at the Gist version & adding the “-layout de” argument to the 2nd setxkbmap command? See if that fixes either the GUI or Terminal keymapping. https://gist.github.com/rbreaves/f4cf8a991eaeea893999964f5e83eebb |
Re-reading this I’m thinking this is intentional if you are not using a Terminal based app. All other GUI based apps have the Alt key acting as Ctrl, so that actually sounds like expected behavior. |
Maybe wrongly, I was under the impression that you want to re-create the Mac keyboard behavior for Linux. If that is the case, then please check how the Mac does word-wise text selection and cursor movement in GUI apps. |
Ok, well you are teaching me something new that I was unaware of, although it seems like I might have known this at one time. I just never got into the habit of using it frequently. I had to go to this site to really test this and see it first hand. https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textarea So to translate this into something actionable this is what you would like, correct me if I am wrong? You want the following. Cursor moves to beginning of line Cursor moves to end of line Cursor moves to beginning of text Cursor moves to end of text Cursor moves to beginning of existing word Cursor moves to end of existing word That would make sense and while it can certainly be supported with 3rd party tools like autokey I'd rather support it using xkbcomp if at all possible. I will look into this. |
Thanks for looking into this, appreciate it 👍 What I want is if I close my eyes, imagine the keyboard in front of me belongs to a Mac, and do what I would do on the Mac, that it then works even it is not really a Mac but a regular PC keyboard on a Linux system ;-) |
I will try and look into creating a solution for xkbcomp by following the advice I have found here. You are welcomed to try it though if you are inclined to get to it before I do. The person in that thread isn't trying to create the exact same type of key layout but it is very similar and I think it could work really well. https://geekhack.org/index.php?topic=70788.0 Also just to note, setxkbmap and xkbcomp are compatible with Wayland, unlike using Xmodmap. I would ignore solutions that involve Xmodmap, because it also involves using xev a lot of the time and knowing specific key values that may not carry over well to other region keyboards or even within the same region. Xmodmap is just a very non-portable mess in my view with no future. |
This site appears to have a more complete list of text manipulation under macOS. https://www.danrodney.com/mac/#working-with-text For linux I should be able use this site about gedit shortcut keys to re-align everything related to text manipulation in GUI apps anyways to match macOS. https://hamwaves.com/gedit/en/index.html I do not know if it'd be a good idea to attempt to keep that key layout for Terminal apps or not. They often don't work on macOS while in the terminal any ways or if they do it works under the official Terminal app and not iTerm2 or any 3rd party Terminals. |
Not the solution I wanted, but a solution nonetheless, one of the possible solutions I had mentioned. I will leave this open for now. I will contact the original author before including this in Kinto, but really I want to figure out the xkb method - it'd be faster and as native as it gets.
It should say
My thanks goes out to the original author of those autokey scripts. It's a lot simpler than trying to hack what I want into the xkb files, as that was proving to be really difficult. I still want to do that, but in the short term this solution will get you what you want and can be extended with a fair amount of ease. |
Another issue to note is that with the autokey solution you cannot define different shortcuts between the left or right ctrl or alt keys, even in the instance where the right alt is actually an overlay key on a chromebook. This is problematic, because it treats my overlay key, a pseudo fn key, as the right control key and it overrides its behaviors, which I want to keep. All this really means to me is that it makes me want to merge the text manipulation shortcuts into the xkb keymap files, and specifically on the left. Beyond that though I would not want to do anything further, autokey is a good solution for specific apps that need specific behaviors, but for behaviors that are system-wide or mostly system-wide then xkb is the better option. At times there is noticeable lag with autokey when switching between apps, which reminds me why I gave up on it 3 years ago as a solution for changing my key behaviors specifically in terminal apps - it wasn't fast enough for how frequently I switch between the terminal and everything else. If xkb was easier to work with I'd say it'd always be the best option when combined with xprop (spy) or any type of app that can listen to window name changes. I don't feel like autokey, using python, is hooked into the OS well enough to listen for wm_class name changes as quickly as xprop or kde plasmoids can. |
Wow, I had no clue how complicated all of this seems to be... |
Well I will keep working on it, I can't give an ETA and I may have to reach out to other people to accomplish this or have someone better skilled at xkb than me to take a crack at it. Honestly if I could just have one good, working example of how to remap an Alt and Ctrl key combo I'd be off to the races, but so far every attempt I have tried at it has failed. It could be something both relatively minor and obvious that I am missing here. |
The control arrows now work as expected in the Dev branch via proper xkb config files. Please checkout the dev branch and re-run the installer if you wish to test it. I will be closing this ticket in the next 24-48 hours as I believe the issue is resolved. Just to note for reference, this website link below contained the answer, more or less - although parts of it went into more complication than what was actually needed by step 6. It also did not help that Glen Whitney showed 2 examples through part of it when one would have sufficed. It just made it look even more complicated than what it needed to, but understandably he was trying to be thorough. https://superuser.com/questions/385748/binding-superc-superv-to-copy-and-paste |
Thank you very much for implementing this, highly appreciated. |
Just to At @probonopd you, full Alt + Left/Right support has been added. Previously sublime just supported it by default, but other apps like VS Code did not. I think everything will support it now. More details can be found here. |
For my use case, I don't want this mapping. I would like Cmd + Left, Cmd + Right, etc. to not map to the home key and just stay Cmd + Left. Is there any way to turn this off?
|
In the latest 1.2 release just edit the config if in Linux & find the word wise entries aka RCtrl+Left under the None (GUI) section. Windows is ~/.kinto/kinto.ahk & more info is in the ReadMe. |
Thank you @rbreaves. I'll try this out. |
For Linux which config file would I edit? It seems like there are multiple config files inside the package. |
The one that says Edit Config in the GUI or system tray under edit or customize respectively. Why I didn’t bother to say the location, although fairly similar to Windows but ~/.config/kinto/kinto.py instead. |
As a possibly unintended side effect, Ctrl-ArrowKeys don't work anymore in text entry fields; one now has to use Alt-ArrowKeys. Is this intentional?
The text was updated successfully, but these errors were encountered: