I am a beginner user of emacs. Even after I have deactivated the mark by pressing ctrl+spc still the text gets highlighted when I move across the text. Emacs works fine before I set mark for the first time while editing a file. Once I use the mark this problem begins.
Why do you think that you have "deactivated the mark by pressing C-SPC"?
Do you have transient-mark-mode enabled? (It is enabled by default in Emacs 23 and later.) If so, the you do not see highlighting by default - the mark and region are not active, and if you hit C-SPC once then you see highlighting when point is moved away from the mark that C-SPC just set - the mark and region are active.
When the region is active, you can hit C-g to inactivate it, removing the region highlighting.
If this is not the behavior you see then probably something in your init file is causing the problem. In that case, try starting Emacs without your init file: emacs -Q. If the problem goes away with emacs -Q then recursively bisect your init file to find the problem.
Related
I've just installed Fedora 23 and I've encountered a problem I've never seen in many years of using Emacs.
Emacs won't allow me to highlight text. I noticed it first when trying to click-and-drag with the mouse, but then I tested it by setting the mark and moving the cursor - no highlighting.
The <drag-mouse-1> command description indicates that dragging should set a region and highlight text. Transient-mark-mode is enabled, and I'm running Emacs in its own (non-terminal) window. I can't find any other information about this. Any ideas?
Edit: On closer inspection, I can act on the region that I try to highlight as normal (cutting, copying, etc.). It seems like Emacs IS highlighting, it's just not SHOWING the highlighting. A less serious problem, but one I'd still like to fix and don't know how.
Sounds like the highlight color is the same as or similar to your background color. Try M-x list-faces-display and look at face region. That also provides you an entry point for changing any of the faces displayed - just click the face name to open Customize for the face.
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.
When I select a region by clicking and dragging a mouse across the text, the selection shows up highlighted, as expected. However, when I do the same by hitting M-<space> to set the mark, then moving the point with the arrow keys, the region doesn't show up highlighted. I can yank it, but I can't call things like replace-string on it, suggesting that the region is not active.
This guy seems to have encountered a similar problem in emacs 22 (I'm using 23), and his fix was to call M-x transient-mark-mode to enable that mode. Unfortunately, I already have (custom-set-variables '(transient-mark-mode t)) in my .emacs file. Indeed, when I run M-x transient-mark-mode, I get the message "transient-mark-mode disabled", suggesting that it had been enabled before.
Any suggestions as to what might be going on, or things I could try to shed more light on the situation, would be greatly appreciated.
Bisect your init file (~/.emacs) until you find the culprit code. You just need to make sure transient-mark-mode is turned on only once. You can also just put (setq transient-mark-mode t) at the end of your init file. Unless actions you take interactively cause some other library to be loaded that changes the value of that variable, that should ensure that the mode is on.
The first thing to try, however, is just M-x transient-mark-mode, to be sure that the mode actually works for you. If not, again, bisect your init file to find out what breaks it.
In emacs, especially when ssh'ed into a remote machine, there's a delay between when I type a closing quotation mark and when emacs updates the syntax-highlighting to reflect that change. For a few seconds, all of the text after my quotation is highlighted as if it were part of the quotation. Usually this is fine, but sometimes I'd rather not wait. Is there a way to tell emacs to "re-highlight everything right now"?
Yes. The emacs command is M-x font-lock-fontify-buffer if I recall it right. You can bind it to a key sequence if it's not already bound in your mode.
Twice in the past two days, I've had a problem with my emacs sessions. Somehow emacs is keeping the focus within one frame. So, if I mouse over another frame and click in it, the cursor in the new frame stays put and the cursor in frame 1 moves as if I clicked in the corresponding position in it. Same happens with mouse-wheel scrolling. But not keyboard input.
Killing the hogging frame just causes another frame to become the hoarder.
My solution yesterday was to quit and restart emacs.
Some googling pointed me towards the variable focus-follows-mouse, but that appears to be set correctly (i.e. "t").
Any ideas what caused it and how to reset it?
(I'm using Ubuntu intrepid's package of emacs 22.2-0ubuntu2.)
I have
(setq focus-follows-mouse t)
(setq mouse-autoselect-window t)
in my .emacs file, and find that this makes focus follow mouse work correctly. Maybe there's something else in your config that's changing emacs' behaviour, do you have your elisp in version control? Can you identify when this started happening, and look at changes to your elisp around then ?
Try starting emacs with --no-init-file and seeing if the undesired behaviour persists.
I have discovered that switching to another tty (eg crtl-alt-1) then back to whatever tty you were on before will reset your focus.
Not a general solution, but at least you don't have to kill X (which is what I've been doing until now).