Since I upgraded magit, executing magit-status replaces my patiently crafted window arrangement with a single, huge window. Ok, when quit magit it restores the frame layout. However, I never quit magit. I much prefer the old behavior, where magit-status stayed in the windows in which I ran it. Can I get the old behavior back?
There was no such change it Magit itself.
Are you using some "starter kit"? If so you should probably check there first.
Related
See further below for the original question.
I've used gdb for over a couple of decades, and after an update gdb started defeating c-x-b and preventing windows from being used to view things I wanted to see, while forcing bindings to buffers I didn't care to see. The fix seems to have broken tab completion for shells.
Ah, so how can I to stop gdb from taking control of the buffers/windows/frames layout without breaking something else?
;; fix 'feature' of broken gdb where it takes control of an
;; emacs window, and locks the user out from switching from it
;;
(defun set-window-undedicated-p (window flag)
"Never set window dedicated."
flag)
(advice-add 'set-window-dedicated-p :override #'set-window-undedicated-p)
--- problem in the original post --->
about a year back, after an update, file name completion windows in the shell stopped closing after the completion. I figured this behavior would go away on the next release .. but it never has.
hitting tab -- all good
after completion, then another ls with tab
I can repeat this process until my shell panel is all but crowded out, and emacs fills with completion panels that all contain additional views of the shell.
Is this some kind of new feature that can be turned off? Or is it, as seems more likely, a bug? (How can it have lived for so long!?). Is there a simple way without taking one's hands off the keyboard to, in general, close the completion window so that the screen looks like it did before hitting tab?
[I had to take out the more detailed descriptions of the images because with them, stack exchange complained of unformatted code and wouldn't take the post... there was not even a hint of code in them. Anyway, this should be good enough.]
(Emacs newbie here)
Sometimes a Help buffer gets opened in my emacs editor. It opens in a different pane, splitting the current window into two halves vertically.
When I use C-k buffer-name, to kill a buffer (say Help), some other buffer (say scratch) gets opened automatically in that pane.
Is it possible to revert to my previous configuration, after a random buffer (Help or Debug..) gets opened.
My previous configuration would be to go back to a single window with no panes
To revert to the previous window configuration after any arbitrary change(s), you should enable winner-mode in your .emacs file:
(winner-mode 1)
Then you can use C-c<left> (repeatedly, if necessary) to undo window configuration changes with winner-undo.
C-c<right> calls winner-redo which returns you to the most recent configuration (immediately; not in single steps the like the 'undo' command).
Winner mode is the key to never ever getting annoyed by Emacs creating an unwanted window, but it also lets you do things you wouldn't have done before (for instance C-x1 to maximise one of your windows temporarily for easier reading, because getting back all the windows you just deleted is now trivial).
Obviously this is also incredibly useful if you accidentally mess up your window config!
Hello to revert back to one buffer you must hit C-x1 while standing in the buffer you want to keep. And to switch between frames C-xo
I have two windows open in my Emacs session. Both are remote files opened using tramp. I make a change in window A and switch to window B without saving file in window A. When Emacs decides to autosave, the buffer displayed in window B is switched to the buffer from window A that was autosaved. This only happens when using tramp, not local files.
Another thing I have noticed is, that if I have the same file opened in two windows, because I need to reference something at another position in the file and save the file, the buffer I'm in sometimes jumps to the position that the point is in the other window, so I have to move around to get back to the place where I was editing.
Is this a bug or is there some setting that I have(n't) set? I suspect it is something related to refreshing the windows when saving.
i'm using Emacs 24.3 on OSX, but I have seen this using Linux too.
Sounds very much like a bug, to me. Can you reproduce this starting from emacs -Q (i.e., with no init file)?
If so, use M-x report-emacs-bug to give Emacs Dev the recipe. If not, bisect your init file recursively until you locate the culprit code. Then ask for more help here, if it's not clear how to fix the problem.
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.
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.