AltGr remapped to Context Menu - keyboard

I have an xps13 8350 with an azerty French keyboard on Windows 10.
My AltGr key started to act like ContextMenu out of nowhere.
I was coding and all of a sudden I couldn't use [], etc. anymore. As far as I know, I didn't do anything specific.
I tried rebooting and go into advanced options and then command prompt, my keyboard was behaving as expected in there.
I don't use any remapping, no AHK, etc.
I tried using different keyboard mappings in the Windows settings with or without AltGr support, the behavior is the same on every mapping.
My guess is that I must have done something weird with Fn but I'm not sure how to undo it.
EDIT: I should probably mention that locking Fn or not doesn't do anything;

I fixed it by reinstalling windows.

Related

Can I disable autocomplete with Alt+Tab on Qt Creator under Linux?

For the most part I very much like Qt Creator, but a few projects I'm working on require me to switch between my editor and my web browser for reference. Qt Creator is currently interpreting Alt+Tab to autocomplete, and then switching my window focus; this is a mild problem but it's really starting to get to me.
I've tried going to Tools→Options→Keyboard and searching for Alt+Tab, but found nothing. Is there a way to get it to selectively ignore the key combination without disabling autocomplete on the whole?
To complete the picture, I'm on Linux Mint 19.04 using XFCE desktop environment; or occasionally Maté. If I need to access something in system settings to do this I'm happy to; I just don't want to keep excessively second-guessing my code when I return to it.
Auto-complete is bound to Ctrl+Space by default, not Alt+Tab. In tools/options/keyboard, search for "CompleteThis" to see what it's bound to.
Maybe what you want is to disable auto-complete and use only manual-complete? That is, have the auto-complete list only show when you press ctrl+space, but never automatically. You can do that in options/text editor/completion.

Bépo keyboard layout has been sabotaged in Ubuntu 17.10

I've been using the Bépo keyboard layout for years in Ubuntu, labelled as "French (Bepo, ergonomic, Dvorak way)".
Since upgrading from Ubuntu 17.04 to 17.10 (Artful Aardvark), I now have to use Ctrl+Shift+V to paste, instead of Ctrl+V. This is unintuitive and I'd like to change it back, but I'm not sure how to revise it. In the system settings, there are keyboard shortcuts for starting the terminal etc, but nothing about sabotaging the effect of buttons such as Ctrl. There are no shortcuts listed for copying or pasting.
I suspect that Ubuntu itself has used a faulty key file, as I recall having a similar problem with Windows a while ago, having to mess around with Microsoft's Keyboard Layout Creator.
In Windows I'd experienced a phenomenon where the right alt key had been implemented as ctrl+alt or something along those lines, so I figured that maybe in Ubuntu, the OS was using an odd combination, capturing a potential combination for something unrelated.
I went into the keyboard settings and disabled lots of various combinations that I don't use; then «paste» is working again! There was nothing with a V, so this seems odd. Maybe there were side-effects happening somewhere along the way.

AutoHotkey diacrictics mappings not working correctly with Vim

I've been using some mappings in Vim to avoid having to switch keyboard layouts to type in diacritics in my language (Croatian). However, now I wanted to move these mappings "up" so that they're available globally. I tried using AutoHotkey for this. Here are the mappings I wrote
#CommentFlag //
!;::Send {U+010D} // č
!'::Send {U+0107} // ć
!]::Send {U+0111} // đ
![::Send {U+0161} // š
!\::Send {U+017E} // ž
These work great in every application I've tried (browsers, notepad, MS Word), but don't work in Vim, which is pretty annoying as I do most of my typing there. More specifically, only 'š' and 'ž' work as expected, while both Alt-; and Alt-' give me a 'c' (instead of 'č' and 'ć'), and Alt-] gives a 'd' (instead of a 'đ').
I'm using AutoHotkey_L (though I had the same results with the "regular" AHK), Vim 7.3 (trying this in gVim; it doesn't work in the terminal version either (in a slightly different way) but I don't really care about that) on Win8.
I can give more info on the Vim version, but it's basically one of those windows binaries from vim.org. Things I guess might be important is that it has +multi_byte, and I've been using Unicode in it with no problems whatsoever.
Update:
As per Ingo's suggestion below, I've tried using IfWinNotActive to not have the mappings present in Vim and continue to use my old ones there. Here's one example I've tried
SetTitleMatchMode 2
IfWinNotActive GVIM
{
#CommentFlag //
!;::Send {U+010D} // č
!'::Send {U+0107} // ć
!]::Send {U+0111} // đ
![::Send {U+0161} // š
!\::Send {U+017E} // ž
}
I've also tried many other variations with the Vim window class (using ahk_class), with #IfWindowNotActive etc., but to no avail... The mappings are still there in Vim. Btw, the window title always contains the string "GVIM", and AHK sees that as I've confirmed with WinGetTitle.
I don't have a solution, but a workaround: When I faced with the same issue, I decided to emulate Vim's digraphs globally (also using AutoHotkey), and just except Vim (and applications like Remote Desktop) from that feature (so that the full range can still be used there; my script only supports a subset). You can find my implementation here.
You can also edit a keyboard layout itself, using Microsoft Keyboard Layout Creator.
For example, the English one that you use: choose combination of some character and some function key (Ctrl or Right-Alt, with or without Shift − e.g. for Caps).
Here’s how it looks:
I find the Apple International US layout very good for this purpose, having all the accents available using dead keys, so I've implemented it with Microsoft Keyboard Layout creator like stansult suggested.
Then I came up with the problem of having only one "Alt" key usable, so I ended up remapping my Windows and Alt keys using ScanCodemap. This is a viable solution if you don't use the Windows key that often. One caveat of this method is, that you'll have to use Win+Tab instead of Alt+Tab from now on to switch between windows, it takes a couple of days to get used to that.
Windows Registry Editor Version 5.00
; 0x003a001d: Caps Lock (0x3a) -> Left Ctrl (0x1d)
; 0x0038e038: Left Alt (0xe05c) -> Right Alt (0x38)
; 0xe05b0038: Left Windows (0xe05b) -> Left Alt (0x38)
; 0xe05c0038: Right Windows (0xe05c) -> Left Alt (0x38)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,05,00,00,00,1d,00,3a,00,38,e0,38,00,38,00,5b,e0,38,00,5c,e0,00,00,00,00

Shortcut with meta-shift key doesn't work in emacs

I can't use any shortcut that has meta-shift (alt and shift) in it because ubuntu will treat it as "change keyboard layout" shortcut (I map it to alt-shift since I use the same shortcut in windows) as soon as I press m-s. In windows change keyboard layout shortcut doesn't register until you release the key so any shortcut with m-s is usable in windows.
Is there any work-around without changing shortcut or meta key ? I kinda used to it.
Change the Ubuntu change-keyboard-layout shortcut, to something else.
Or use Esc as Meta
Nothing easy that I know of.
You can manually bind everything that's M-S-??? to C-M-S-??? in your .emacs or at least all of the ones that you use...
Or you can just change the short-cut... how often do you change the keyboard layout? (I use dvorak, and qwerty, but I've never needed a shortcut for it, I just use the button...)
I have tried different things, and in my opinion it is best to change the layout shortcut to something else. The power of emacs is all in its shortcuts that are available right there under your fingers. If you move the M key away and make it harder to reach, it will most surely have a negative impact on your editing speed.
Right now I'm trying to get used to switching layouts with the right Alt key. I almost never use it for anything, so missing it won't be a problem. And from my experience teaching yourself to switch layouts with another combination is a matter of several days.
P.S. Also it pays to use Caps-Lock as an additional Ctrl key, it helps tremendously!

M-f, M-b bindings not working on Mac X11 (through NX)

Business as usual: I've logged into my Linux machine from my MacBook Pro using NX, opened a terminal, and ... key bindings with M- (Meta-) do not work. (Talking about bash, of course.) Wait for it. I'm using a PC keyboard hooked up to my Mac (I cannot work on a cramped laptop keyboard). So I decided to investigate: used xev to capture events. When I press left 'Alt' on the PC keyboard, 'xev' reports that 'Meta_L' got depressed. Problem is, it seems that it gets ignored for some reason (no idea why).
It is really annoying, because the same is true for Eclipse. Practically all key bindings with Alt- in them are gone.
My hunch would be to use xmodmap to force the left Alt key to actually emit 'Alt_L', but I wanted to hear a second opinion.
It turns out, the problem was that, according to 'xmodmap -pm', Meta_L and Meta_R were not in Mod1 special modifier category. When I moved them there, everything started to work. (Turns out, some programs assume, incorrectly, that 'Mod1' is Meta/Alt, and ignore keysyms like Meta_L.)

Resources