(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
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.]
I am new to emacs and have been referencing the tutorial frequently in the course of editing my file.
To go to the tutorial from within the file I am editing, I do: C-h t.
After consulting the tutorial I am ready to close it to return to my file.
I do C-x C-c.
But then I need to open my file once again, doing emacs <file> to return to it.
I am looking for a faster way.
Is there an emacs command which will close the tutorial, immediately returning me to the file from which I opened it?
As #torazaburo mentions, if you really want close the tutorial, you can use C-x k (AKA kill-buffer) to close/kill the tutorial buffer. However, in this case you will first be asked if you want to save your position in the tutorial, and you will be asked if you want to pick up where you left off next time you do C-h t. You may find this tedious depending on how frequently you switch.
Since you mention that you reference the tutorial frequently, in some cases it might be a better option to simply switch back and forth between the buffer you are editing and the tutorial, rather than opening and closing the tutorial.
One way to do this would be to use C-x b (AKA switch-buffer) where the last buffer you visited will be the default buffer to switch to, so you can use C-x b RET to toggle between your tutorial buffer and the buffer you are editing without loosing your place in either.
Another similar option is to use C-x followed by the right or left arrows to cycle between the buffers: C-x and left to go from your tutorial buffer back to your edit buffer, and C-x right to go back to the tutorial.
However, note that one downside to the methods I describe above is that, while switching away from the tutorial buffer and back to it will save your position for that session, it will not save it for future sessions. If you then use C-x C-c to quit Emacs and open the tutorial again, you will have to find your place if you have not saved recently. C-x k has the advantage of prompting you to save each time, but also has the disadvantage that it prompts you each time, i.e., if you are constantly switching back and forth, you may not want to answer yes or no each time. Choose the solution that works best for you.
When calling ediff, run-python and some other commands, emacs will open a new frame, but I want emacs to open new window instead, is that possible?
Dunno why someone voted you down. Perhaps s?he thought you should have looked first in the Ediff manual (which I too recommend).
a. Command ediff-toggle-multiframe toggles between using multiple frames and a single frame (multiple windows).
b. The Ediff manual says also: "See ediff-window-setup-function for details on how to make
either of these modes the default one."
You will need to check whether Python mode similarly provides options or commands to control the window/frame behavior.
If Emacs is always opening a new frame for everything, then make sure you do not have a non-nil value for option pop-up-frames.
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.