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.
Related
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.
In my .emacs file I have (delete-selection-mode t) to enable the delete-selection-mode globally. Currently I'm working on a TeX file with AUXTeX, so it might be related to AUCTeX, but I don't know.
At first, after visiting a file foo.tex everything works fine, and typing over a marked text replaces the marked text with the one I type. However, after some time, during which I compile the document, add TeX macros, etc. the functionality of the delete-selection-mode doesn't work any more.
I don't know which action of mine is the one which causes the problem - it would be hard to trace it.
Note that although the functionality of the delete-selection-mode fails, when I try to enable it (M-x delete-selection-mode) I get a message that the mode was disabled! That is it was not disabled before - it just didn't work... I I then enable it (M-x delete-selection-mode again), then it is enabled and working again. Till the next fail...
Under the hood, the mode use pre-command-hook, which allows commands to run things right before every command. Emacs is known to clear this variable in the event of an error (just to make sure that Emacs don't hang). This mean that the function used by delete-selection-mode, or any other mode that use this hook, triggered an error.
How to fix it? Find what caused the error, wrap the function in a ignore-errors block, or run a timer re-adding the function every ten seconds or so.
I'm developing a mode for Emacs, and everytime I switch to its buffer, viper gets turned on. I've modified viper-mode to trace where viper-mode is being called, and surprisingly set-viper-state-in-major-mode is called by running the viper-post-command-hooks, set to nil. Any idea of what is going on?
Thanks!
EDIT: For the benefit of all beings, here is what I found out: as instructed by Trey, I started emacs with -Q and manually loaded both viper and my package. As I could reproduce the bug, the problem was on one of these packages. After line-by-line filtering, I discovered that the innoquous-looking (kill-all-local-variables) was causing the problem.
There's something in initialization that's causing it.
First try starting without your .emacs emacs -q. If the problem persists, then the trigger is in the site-start.el. So, talk to whomever installed Emacs and get them to remove the customizations there. You can also always use the -Q startup option to avoid loading the site-start.el.
If the problem isn't in site-start.el, and you don't think it's in your .emacs, it might be in a custom default.el file, which you can prevent from being loaded by adding:
(setq inhibit-default-init t)
to your .emacs.
If you still have a problem, then I'm 99% sure it's in your .emacs.
To be 100% sure, try emacs -Q, which runs Emacs with no customizations. If the problem persists, download and install your own Emacs b/c you surely can't trust the installation you're using.
So, now if you're convinced it's in your .emacs, start cutting out parts of your .emacs, or introduce an error in your .emacs with (error "frog"), and progressively rule out which portions of your .emacs are causing the problem.
g'luck
The function kill-all-local-variables will run all functions added to change-major-mode-hook, this is a common way for global minor modes to initialize themselves. For example, global font lock and global cwarn mode use this.
I haven't used viper myself, but chances are that it use this mechanism. Of course, you still would have had to enable it in your init file, somehow, so if you simply would stop doing this, it would solve your problem as well.
Try commenting out any references to viper mode in your .emacs. I don't get sent into viper mode, unless I start playing around with viper mode before I eval your new mode.
Maybe there's more being done with this statement than you think:
(use-local-map ecoli-map)
Try to change some of your binds in your map. eg. j to C-j and k to C-k.
Maybe emacs is getting confused?
Try removing your ~/.viper config file, and also check your .custom.el for settings that might kick viper into action in your major mode (or globally).
I am not even sure this is a previous command or a non-finished command or whatever, but I do know I really don't like it.
My problem is that some commands (or messages, or whatever) get stuck in the mini-buffer so that when I type a new command it appears there really quickly, and then the mini-buffer is back to the stubborn command. Some commands seem to be chosen, and after using lots of commands something else gets stuck there, but there is always something being shown that I don't want to see. I tried typing C-g lots of times to see if it would quit, but that does not work.
This is a picture of what I have now:
It does not matter what I do, that bit
Label: hl-line
will not leave. It does leave momentarily when a new command is typed, but it goes back. I don't like it, it is confusing, and I would much rather see there the last used command.
I did check the customisation options for the mini-buffer (the bottom part of it can be seen in my picture), but I found nothing that seemed to be what I was looking for.
Any ideas?
Chances are you're getting into the situation because you started a command and used your mouse to select something in a different window. If that's the case, you can have Emacs automatically abort the command when you do such an action.
This is the code you'd add to your .emacs:
(defun stop-using-minibuffer ()
"kill the minibuffer"
(when (and (>= (recursion-depth) 1) (active-minibuffer-window))
(abort-recursive-edit)))
(add-hook 'mouse-leave-buffer-hook 'stop-using-minibuffer)
Note: I grabbed this from my blog post on the topic.
And there is also a super user question that addresses this issue, and my answer there provides a command to jump back to the minibuffer.
The mini-buffer has lost focus. Try C-x o (Control+x o) to regain focus. To cancel the command press C-g when you have focus in the mini-buffer.
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).