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.
Related
It has been like one year or so since I started to learn Emacs, and I do like its power and flexibility as a general text editor. When I had tried its Auctex mode for LaTeX/TeX, I knew I will never go back to read which TeX editor I should use. When I had tried its Pyhon mode, I knew I will never be bothered to choose a Python editor/IDE. Well, the same feeling for the VHDL mode of Emacs.
I do not intend to implement Emacs as a whole FPGA design solution (although I tried that). Instead, I prefer to use Emacs just as an external editor (Xilinx ISE in my case) and follow the design sequence according to the ventor's specific IDE. So according to this Editor Options, I set the editor options in my ISE {C:\Program Files (x86)\emacs\bin\emacsclient.exe} +$2 $1. However if I use runemacs.exe as suggested by Xilinx, everytime I clicked a file in ISE a new Emacs will be started. With the emacsclient.exe it helps a bit.
When I clicked a file in ISE now, its corresponding buffer will be opened in Emacs. But the buffer remains invisible and I have to C-x b to it by my self.
Also if I clicked the error information in ISE's console, the file containing the error will be opened in the background of Emacs with the cursor in the error position.
While it is not a big deal if I compare the benefits and drawbacks brought by Emacs VHDL mode, I do like Emacs can change the file I opened in ISE to the current buffer. So the question is how to set Emacs or Xilinx ISE to change Emacs's current buffer to the one I opened or clicked in ISE?
I suppose it should be some configuration related to Emacs rather than settings in ISE (obvious there is not too much choice in ISE's options). It maybe a simple question but it's beyond my current knowledge of Emacs configuration. I really appreciate if someone here could help me on this issue. Thank you guys in advance:)
P.S. Sorry for my poor English expression. Hopefully you can understand my quesition.
With some configuration it's possible to tell Emacs to switch to the related buffer. However, you might want to consider opening a new window (frame in Emacs term) when you call the editor in ISE.
The command line parameter -c tells Emacs client to open a new frame
{C:\Program Files (x86)\emacs\bin\emacsclient.exe} -c +$2 $1
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.
I recently switched to using GNU Emacs 24 from 23, and I notice that whenever I enter gud the *input/output* buffer is open. I have close it manually with C-x 0 everytime I debug. Can anyone point me to the correct variable which needs to be configured in order to stop displaying this buffer by default?
There is a 'gud-gdb' in new emacs releases that implement the old behavior of gdb/emacs interaction (no dedicated-windows and no I/O buffer). If you don't want to call M-x gud-gdb when you use it you can define an alias for M-x gdb
I have this problem as well. After a quick look at the source code, the problem appears to be that GUD dedicates most of its windows (that is, it calls set-window-dedicated-p on them). A dedicated window is one that cannot be switched away from. I guess more and more young guns are using GUD in many windows mode and want GUD to manage their window layout, and those of us that like to do that manually are in the minority. There doesn't seem to be anything obvious in gdb-mi.el that disables this behavior (for example, gdb-set-window-buffer seems to always do a set-window-dedicated-p to t for all windows it manages).
For now, this solution is more or less the one I'm using -- I manually deactivate the window dedication. This seems suboptimal, though. There ought to be some way to get GUD to let you manually manage the window layout. This question is related.
You can disable window dedication altogether like this: (in Emacs 24.4+)
(defun set-window-undedicated-p (window flag)
"Never set window dedicated."
flag)
(advice-add 'set-window-dedicated-p :override #'set-window-undedicated-p)
Note that this doesn't affect already dedicated windows.
I have to use xterm-mouse-mode to support mouse when using emacs via ssh, but i found it will not highlight the whole word when i double click on a character of the word. Instead it only highlight the character under the mouse. How can i fix it?
C-h f xterm-mouse-mode says:
...works for simple uses of the mouse. Basically, only non-modified
single clicks are supported. When turned on, the normal xterm...
So, I'm afraid double clicks are known not to work (they are seen by Emacs as 2 normal clicks).
EDIT 2014-Aug-29: This limitation has been recently lifted in Emacs's trunk (i.e. not in the upcoming 24.4 but in the next version instead).
Highlighting does not work in the non-windowed version of emacs (emacs run in a terminal window). It's hard to tell whether things are being highlighted which is why I recommend using C-space (Mark-set) to highlight things instead as it gives you a little more control rather than enabling xterm-mouse-mode as sometimes you may not double click correctly.
How do I customize which window GUD will use when i issue commands - 'up', 'down', etc ? It seems to use an arbitrary window, sometimes even the window with gdb in it - I want to be able to specify a specific window to be used.
Have you considered borrowing the key bindings mentioned in the following question?
Emacs, switch to previous window
This question implies that GUD steps on some things if you don't add a parameter. Maybe your command bindings are being affected similiarly.
Using gdb in Emacs 23
I asked a buddy of mine about this issue and here is what he said.
Well, we used xemacs and so it's not exactly apples to apples here. I
do have gnu-emacs installed on cygwin and I can't replicate his
problem. I think he definitely needs to list a version # for emacs
and the version # for all his installed packages.
When you press up/down it calls 'previous-line' and 'next-line'
respectively which both move the cursor in the default buffer. The
only thing I can think is that he has something running that switches
buffers (lisp 'set-buffer') temporarily and maybe doesn't set it back
or errors b/f restoring the buffer? Better to use
'with-current-buffer' (or one of the other with-* forms) that saves
the current state of the ui runs your lisp code and restores the ui
state.