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).
Related
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.
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've been using a copy of emacs (in a Debian VM I ssh to with putty) at work for a couple of months now, and up until now everything has been working brilliantly... but this morning I'm trying to edit a file in shell-script-mode, and am seeing some weird behavior with text around the cursor.
Basically, when I type the following ( [ ] represents my cursor):
export DATABASE[]
After I've typed the first few characters of the variable name the export statement disappears and the variable name aligns to the left margin, and all I end up seeing is (with the cursor out in the wilderness):
DATABASE []
If I then hit CTRL-L, the screen refreshes, and I see the text as it should be displayed... until I start typing, and then the buffer start acting strangly again (characters disappearing, moving, cursor ending up in the wrong place, etc)
I've not, to my knowledge, added anything to my .emacs file since this last worked as I expect it to, so I'm at a loss as to what could be happening here. It doesn't seem specific to sh-mode either - I've tested a few other file types and observed similar strange behavior. Are there any emacs afficianados out there who might be able to point me in the right direction to figure out what's wrong here?
Thanks in advance
I'm not sure what to suggest, but this sounds awfully like an issue with the terminal: I suspect that Emacs redraws the current line whenever it changes and I guess it tries to do so incrementally. If something's got out of whack with your terminal, then it seems quite plausible that the current word would get written at the start of the line (all Emacs sent) and your cursor would get abandoned "out in the wilderness" :-)
Obviously, this is a new change. Since it doesn't sound like the sort of issue that would be caused by Elisp configurations in your .emacs, you should check whether you've recently upgraded one of
PuTTY
Emacs version
SSH version (unlikely...)
Then maybe the relevant tool will have something in the changelog (which maybe you can disable via a config?)
One thing you could check: you say this isn't just SH-mode. Is it "any mode with syntax highlighting"? Maybe Emacs just sends over the wire the text with the current colour?
I had a similar problem of disappearing text using PuTTY / Emacs / Remote AWS Ubuntu when running ABCL LISP in a shell window.
The solution was: I had changed my foreground and background font colors (essentially reversed) in PuTTY but had neglected to change the bold fonts, so they were disappearing into the background.
Emacs23 GUI in Ubuntu 10.04 LTS. I've previously not changed any settings relating to Emacs scrolling behaviour. However, today I noticed a peculiar jumping behaviour when scrolling down in a buffer -- the cursor down key would scroll down as normal to a point and then the next keypress down would sometimes scroll the buffer down instead or sometimes appear to scroll the buffer up and then move the selected line down. It appeared to be more buggy behaviour rather than the normal or predictable jumping of the buffer. If I held down the down cursor the screen would jump and scroll and stutter and then lurch forward and then stutter.
I searched for some answers and tried a few mentioned here, but nothing solved the problem. Only then did I realize that this behaviour is new -- it only appeared after I changed the font in the buffer with C-x C--. When I returned the font to the "default" with C-x C-+, the scrolling behaviour returned to normal (the point moves to the last line, then the next press scrolls a few lines and moves the point up and displays the lines below; this is the default I think and I'm happy with it). Ideas?
Edit: Scrolling up works fine (as expected/default) regardless of font-size changes. Changing the font smaller a second time only makes the scrolling more bizarre.
Edit: Temporary workaround: return to using emacs -nw
Update: Tested on another Ubuntu 10.04 machine (desktop). Launched Emacs 23 and loaded a log file. Maximized Emacs. Help down cursor and scrolling worked as normal -- the cursor gets to the bottom, the buffer scrolls and the cursor moves to the middle of the screen. C-x C-- to reduce font size. Scroll down again. Same strange jerky behaviour, where some jumps don't seem to even move the buffer properly. Enlarge font once, and scrolling returns to normal. Scrolling up is fine regardless of font size. I searched the Emacs bug tracker briefly but did not find a bug which matched.
I've had this problem (or something very similar) for a long time. I finally found something (on EmacsWiki) that's working:
(setq auto-window-vscroll nil)
Without this, the buffer will not scroll down correctly when I've altered the font size, regardless of my scroll settings, which are, for what it's worth,
(setq scroll-conservatively 10)
(setq scroll-margin 7)
Consider filing an Emacs bug: M-x report-emacs-bug.
I have recently started using doc-view in Emacs, but I am having quite a few problems with it. The main one is that I can't scroll down on pages. I can see the next or previous page using "n" or "p", but the commands to scroll up and down a page, which are supposedly SPACE and DEL, do not work. Well, to be fair, DEL works, but it goes to the previous page rather than scroll up to the bottom of the previous page. The result is that I can only see the top of the pdf pages, but not the bottom parts.
I tried changing the view to continuous, but that doesn't work either. This is what I tried changing:
I did check the customisations for doc-view, but the variables (or options, or whatever they are called) did not appear to me to be the ones which would solve my problem.
More information: I did manage to make SPACE and DEL work at some point, but I don't remember what I did, and I can't get it to work again. I am using Aquamacs.
Any ideas?
By the way, another problem I have is that doc-view causes Aquamacs to sort of crash, meaning it freezes everything, keeps "thinking", and I have to force quit Aquamacs to get it to work again. While this is not my main question, if anyone can tell me anything about this I would also appreciate.
Thanks!
EDIT: I tried what the answer below suggested, it didn't work, kept trying other things/commands, and then C-n and SPACE started working! I quit Aquamacs, started it again, opened a pdf document, and it is back to not working. Can someone please explain what is happening? How can I make this reliable?
(setq doc-view-continuous t)
This lets you scroll the whole document with mouse wheel(not just the current page).
To commands to scroll down are bind to:
C-n, down
not SPC
UPDATE:
SPC is rebound in docview mode. Can't reproduce you issue using GNU Emacs/Linux, can you invoke:
M-x doc-view-scroll-down-or-previous-page