Several times now while programming in Emacs my keyboard has started to write Greek letters into the buffer. I assumed that I'd pressed some key combination but after searching I've yet to figure out what it is and my only solution right now is to restart Emacs. So what am I doing and how do I fix it?
Try to analyse what you've pressed.
M-x list-command-history shows command history
C-h l runs the command view-lossage which displays last 300 input keystrokes
I'm going out on a limb.
You're working on a windows computer that has multiple input languages configured (including greek). It also has the default keyboard shortcut to switch between them enabled (left alt+shift is the default, and if you have multiple inputs set up, it is on by default).
Some emacs shortcuts require an alt-shift combo, and depending on the order you press them, you get or don't get windows intercepting it for the IME switch.
Possible solutions include:
remove the greek IME
disable the windows shortcut to switch IMEs
change said shortcut
I typically want multiple IMEs on my systems, like that I can switch IMEs quickly, and don't want to mess with default shortcuts, so I ended up getting used to always pressing shift then alt when doing alt-shift combos in emacs.
Related
Strange problem appears on one of my machines.
Hit Ctrl+Tab, just hit and immediate release of Ctrl - should switch to the last used editor window. Should.
But instead I have a drop down with list of editors and have to press Enter to do the actual switch.
Holding Ctrl and hitting Tab several times - acts normal.
The problem I see is on VSCode v1.66.2. Another two machines have the very same version and do not experience that issue. So I am assuming the problem is somewhere in settings but I am at loss which one.
I guess, I had to write the question down to find the answer...
The reason for the problem was in extension. In this case it was "Keyboard Macro Beta". It overrides the default behavior of Ctrl+Tab, for some reason.
Found it by just typing "Ctrl+Tab" in the filter field of Keyboard Shortcuts.
Disable/uninstall the extension and default behavior for the hotkey was restored.
I have a need to use something else than the TAB key to achieve ALT+TAB functionality in Windows 10. (long story short - I'm using Parallells and remote desktop on a Mac, and need to keep the Remote Desktop setting "Apply Windows Key Combinations" set to "On this computer", so I can't just forward everything to the remote computer).
Using Autohotkey on the remote computer, I thought I could simply do something like
§::Send {Tab}
to be able to press ALT+§ instead of ALT+TAB, and have Parallells ignore it and just forward it as any other key (for example SHIFT+A to type an "A"). But it doesn't seem to work that way, nothing happens when holding down ALT and pressing § except a "pling" sound. Just pressing § alone prints a TAB character if I'm in a text editor.
I tried
^!§::Send ^!{Tab}
as well, same result.
For now I settled on using the following script instead, which lets me press § to bring up the ALT+TAB window, where I can either use arrow keys or the § key to select an application, and then Enter to switch to it:
§::Send ^!{Tab}
This is not bad, but it's annoying to have to use the Enter key to activate the window. So, is there any way to simply replace ALT+TAB with ALT+§ and get the normal functionality of the ALT+TAB window-switcher?
Use the hotkey <!§::AltTab.
<! means left alt and you can read more about AltTab here.
Also, AltTabMenuDismiss might be worth looking into related to the problem you outlined in the comments.
I want a trilingual English-French-German keyboard with the Dvorak layout on Windows 7. I made it myself with the Microsoft Keyboard Layout Creator v. 1.4. For some letters I have to assign five variants (e, é, è, ê, ë plus the capital versions). Microsoft Keyboard Layout Creator only allows Ctrl-[key] and Alt-Ctrl-[key] to make alternate characters (not Alt-[key], unfortunately). I had no choice but to use the Ctrl-[key] sequence to produce a lot of keys.
In almost every program (e.g. Firefox) the keyboard has priority over program-defined shortcuts, so that if Ctrl-u is a defined key on my keyboard, the Firefox shortcut with Ctrl-u is frozen. This is what I want in Microsoft Word 2010. But even if I delete the Word 2010 shortcuts in File > Options > Customize Ribbon > Keyboard Shortcuts Customize, Word still has control over the Ctrl-[key] sequence. That is, if I kill the Ctrl-f (find) shortcut in Word, and then press Ctrl-f, nothing will happen: find will not open and my Keyboard assigned Ctrl-f character is not printed.
How can I give priority to my custom-defined characters over Word's Ctrl shortcuts?
Your best bet is probably going to be using AutoHotKey to do your layout mappings. AHK basically monitors the keyboard buffer at the OS level, so it is able to intercept and correct keystrokes before the other programs can react to them. I can confirm that Ctrl+F in AHK does overwrite the keyboard shortcuts in Word 2010.
Some sample AHK code:
^f::Send {U+00C6} ;Ctrl+F sends Æ
!f::Send {U+00C7} ;Alt+F sends Ç
!^f::Send {U+00E8} ;Ctrl+Alt+F sends è
!^+f::Send {U+00C8} ;Ctrl+Alt+Shift+F sends È
^ intercepts a Ctrl keystroke, ! intercepts Alt, and + intercepts Shift, and they can be combined. The {U+xxxx} corresponds to the Unicode number for the given character.
Using this method allows you to keep your keyboard mapping in a simple txt file (easy to backup or transfer to another computer). It also overrides shortcuts in all programs, so you won't have to re-adjust the shortcuts for each new program you use.
I'm using iTerm2 on my mac to ssh into a Linux box and run emacs in the terminal. On a big monitor, I like to split the window to see multiple buffers side-by-side. I'd like to be able to switch to a particular buffer by clicking the mouse in it (rather than doing C-x o).
What seems to be happening is that if I click the mouse anywhere outside the currently active buffer e.g. in the next buffer, on the mode line etc., the click is being interpreted as which is bound to (tmm-menubar-mouse EVENT).
I have disabled the menubar by doing the following in my .emacs_d/init.el:
(menu-bar-mode -1)
This seems to disable the visible display of the menu bar at the top of the window, but the mouse click behavior I described is still happening.
I think what I need is to have the click interpreted as something other than and then bind that to some function that detects which buffer the click happened in and switch to it. But, I don't know how to do that and the searching I've done hasn't yielded any clear answer. Can anyone help?
Alternatively, I looked into using windmove to enable switching between buffers with SHIFT and the arrow keys. I did (windmove-default-keybindings) but emacs then seems to respond to SHIFT left-arrow by inserting "2C" into the buffer and SHIFT-right-arrow by inserting "2D". If anyone has any tips on making this work too, I'd love to hear them.
Thanks
I ran into this problem a while ago, where clicking on column > 95 was interpreted as <menu-bar> <mouse-1>, which invokes tmm-menubar-mouse. It turned out to be a bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6594
There hasn't been a formal release since this bug was fixed, but you can get the patch here:
http://bzr.savannah.gnu.org/lh/emacs/emacs-23/revision/100618
If I recall correctly, you should be able to just drop the modified file into your existing emacs installation and byte-compile it (assuming you're running the 23.3.1, the latest release).
I use Eclipse with Dvorak-QWERTY Commands (a Mac option). I am running OS 10.6. But when I press the command key, it does not revert back to the QWERTY keyboard but instead stays as Dvorak. This makes keyboard shortcuts a lot harder to use. How can I fix this problem?
If Eclipse (or other program) supports remapping keyboard shortcuts, you can just go to remap the shortcut to the same physical key that originally was in QWERTY while your keyboard is in Dvorak, so it looks like the same shortcut but is actually mapped to a different key.
Otherwise, I'd just take the time to learn the shortcuts in Dvorak. It may be a pain at first but you'll be one more step towards being QWERTY-independent.