I have set up my emacs so that I can highlight regions with shift + arrows, PgUp, PgDown, Home and End keys, and in window mode that works fine. In terminal mode the combinations Shift+End and Shift+Home do nothing. All other combinations work. Has anyone else encountered this and knows how to fix it? I'm using Gnome Terminal 3.6.2 and emacs 23.3.1.
Not sure what you mean by "set up my emacs so that I can highlight regions with shift + arrows" since AFAIK this is the default behavior, but if they do nothing I think it's because these key combinations are somehow caught by your window-manager.
At least here on Debian, with gnome-terminal 3.12.2 they work just fine.
Gnome-terminal (actually the underlying vte widget) has recently received many emulation fixes, including fixing the keys with modifiers. Upgrading to a recent version will fix your problem.
I see the same problem on Ubuntu 14.04 with gnome-terminal.
This is a problem with gnome-terminal. If I use XTerm, then it works as expected. There is a similar problem with Ctrl-Home and Ctrl-End. Those keys send the same key code as Home and End.
Related
I have an Arch-linux system and I just installed guix. Using Guix, I installed emacs. When I use the pacman-installed emacs all is well but when I use the guix-installed emacs, the mouse cursor gets really small every time the mouse hover over the emacs window.
I have an hidpi screen which should be the cause but I don't know why the mouse does not recognize the dpi of the system when using guix-installed emacs.
emacs version is 28.1 (same as the system-wide version of emacs)
I use i3 wm
EDIT: I did the test and the problem does not happen when I use sway (Wayland wm) instead of i3. I guess this is a problem between Xorg and guix.
I'm on Debian and I have the same issue as you. I've tried the regular ways to increase cursor size like setting Xcursor.size in ~/.Xresources, but to no avail. Then, I realized that Guix set a XCURSOR_PATH. My fix was to set XCURSOR_PATH manuall in .xinitrc to both the path from Debian and Guix:
export XCURSOR_PATH=/usr/share/icons/:/home/munen/.guix-profile/share/icons
I am not able to set the mark at the current point by C-SPC (both when emacs loads the init file and when it doesn't). However, when I do M-x set-mark-command, the mark is well set and I am able to select the region by moving the cursor. When I do M-x apropos set-mark-command, it shows two bindings C-# and C-SPC, but only the first one works. Any suggestions will be appreciated.
I am running emacs 24.3 on a GUI on Kubuntu 14.04.
Ubuntu 14.04 has an open bug affecting some desktop environments (at least KDE, LXDE and i3, but not Unity).
The default IBus key binding for "next input method" is Ctrl+Space, which prevents this key combination from reaching Emacs (or any other userspace program). To resolve the issue, run ibus-setup and change the key binding for "next input method" to something else (or delete it entirely by clicking the "..." button and then the "Delete" button).
Note that running ibus-setup from Unity, where C-SPC works already, shows a preferences window that does not include the key binding option that needs to be changed.
The "next input method" command cycles through your configured inputs, e.g. perhaps from English to French.
So I tracked down a similar issue to this on macOS. It seems that at some point C-SPC became bound to "Select the previous input source":
I just had the same issue today which I never had before. I am on Windows 7. As it turns out the Ctrl+SPC is bound to the OS's language switch. So the keystrokes are not sent to emacs at all.
But one thing that is even more weird is that I have never installed new languages/keyboards, yet the 'CH PRC' shows up in my language bar as a language/keyboard today. It turns out to be a Windows 7 bug and all I had to do to fix was:
Add 'CH PRC' in the language bar then Save.
Remove the language then Save again.
I know you are not on Windows, so the fix may not be the same as mine, but it is very likely Ctrl+SPC is bound to your OS's language switch as well.
I have just upgraded from Ubuntu 10.04 to 12.04.3 LTS. An annoying thing I discovered is that, in eclipse and matlab, I cannot type text sometimes. The detailed phenomena are as follows:
Eclipse
Happens after using auto-completion (activated by customized shortcut alt+/), or switching from other windows, or pressing ctrl+z, etc.
Can use mouse to move cursor around, but keyboard does not respond.
Using alt-tab to switch back and forth can solve the problem.
And similar things are happening in matlab, whenever I hit tab . But gedit and browser are working fine. Wonder if anyone has encountered the same problem. Thanks.
Problem solved. It's really a conflict between out-of-date keyboard input methods and java programs in Ubuntu 12.04. See https://askubuntu.com/questions/365205/text-editors-in-eclipse-matlab-loses-focus-occasionally-after-upgrading-to-12-04.
I'm currently using Emacs 23.1 on a remote server through putty. I would like to be able to zoom out (so I can view all my code when needed). I've tried several methods and none of them have worked.
Text-scale-decrease and text-scale-increase give no errors but don't change the text size
The zoom-frm plugin tells me that "symbol's function definition is void: query-fontset" when I attempt to use any of its methods (all dependencies listed are installed)
The doremi-frm plugin either gives no errors and does nothing, or complains about face-remap (depending on what function is used)
I'm wondering at this point if zoom is possible within putty, and if so how do I get it to work properly.
P.S. Opening a remote X11 session with the Emacs GUI is not an option.
Thanks.
You need to config putty instead.
Open putty, then right click > Change Settings > Window > Fonts on the left panel to change font size.
What Emacs are you using? You say Emacs 23.1, but that has `query-fontset' (as do also older and more recent Emacs versions, from GNU Emacs 20 to the latest GNU Emacs 24 dev build).
Likewise, GNU Emacs 23.1 has face-remap' and all of its relatives,face-remap-*'.
I can't answer the putty questions, but can you check in some other way whether Emacs at the remote end actually zooms OK using any of the methods you describe? IOW, try to remove putty from the equation, to see what happens.
I use Ubuntu (64 bit). I saw some discussions about Ctrl+Space, but in my case I can't do Ctrl+S, Ctrl+V, Ctrl+Z, Ctrl+Shift+F and, probably, something else (all these cases work fine in other programs, so it's not a keyboard problem). It doesn't work, then it does, then it doesn't again. Is there a way to fix that? Thanks in advance.
I am also using 64-bit Ubuntu (12.04 now, 11.10 before that) and Eclipse. I was having similar problems like what you are describing, until I realized that keyboard input method/layout settings actually matter in Ubuntu (while it does not in Mac OS or Windows) while using copy/paste. If you are using two keyboard layouts (e.g. I am using English and Bulgarian), Ctrl-C / Ctrl-V will not work with the non-English layout. If it does no work, double-check the current keyboard layout.
It took me awhile to figure that out - hope it would help you too.
I've solved the same problem rebuilding my workspace CTRL + B on Windows
Similar problem
Looks like there are some key combination which screw up with the focus in the eclipse editor. Try using the shortcut for Focus Return
Shift+Alt+f