I'm currently programming away in emacs. I have a function defined in my .emacs that saves all my work and executes the interpreter to run my work in the currently open shell buffer. Typically I'll be editing in one or more frames and have the shell open in a separate frame. The problem I have is when I run my save and execute function, everything is saved but the shell buffer then gets displayed in the frame I'm currently editing. So I have two frames showing the shell buffer and I can't see the source code I was just editing. Quite often when I'm programming, I'd immediately like to compare the output of the code with the code I've just written. It's a bit annoying to have to switch back to my code buffer and then go to the end of the other shell buffer to look at the output while referencing the just written code.
(defun execute-script ()
"Switch to shell buffer and re-execute the last command."
(interactive)
(save-some-buffers)
(switch-to-buffer "*shell*")
(end-of-buffer)
(comint-previous-input 0)
(comint-send-input))
As you can see my function is rather primitive at the moment, just re-executing the most recently used command in the shell.
I know that Emacs has the functionality to switch to a buffer in a different frame, as the ido buffer switcher code does this. Does anybody have any pointers as to what I need to replace my call to switch-to-buffer with to get the desired effect?
Regards Giles.
Exchange
(switch-to-buffer "*shell*")
for
(switch-to-buffer-other-window "*shell*")
This will enforce a two window layout with your previous buffer on the left side and the shell buffer on the right side.
Edit: If you're using a multiple frame layout and not a multiple window layout you can use
(switch-to-buffer-other-frame "*shell*")
You can also use pop-to-buffer which will later let you customize exactly how that behaves, e.g. via display-buffer-reuse-frame, or display-buffer-alist, or special-display-regexp.
Related
I have setup emacs -daemon to run on login to Gnome and associated emacsclient with .cpp and .py files that I work with in Eclipse in order that emacs is used as my default editor for these files when selected within Eclipse. This way I can get a good work flow combining the editing capabilities of emacs and the project/build management and debugging facilities of Eclipse.
Anyhoo... I want to prevent C-x C-c from closing the Emacs frame I am currently editing in if it is the only Emacs frame remaining visible at any given moment.
Is there a way of querying the daemon Emacs process in order to find out how many frames are open and override the default C-x C-c behaviour to do nothing (if only 1 frame remaining) thereby ensuring there is always at least one visible frame open at all times?
Some elisp that implements this behaviour and that can be added to my .emacs would be great.
Bonus Points :¬)
I have aliases that map vi, emacs etc... to "emacsclient -c", so I get emacs frames coming and going all the time in general. A further enhancement would be for Eclipse to send files that I want to edit directly to a specific frame e.g. the 1st frame opened with emacsclient -c.
Make emacs immortal (what ever the way you've started it) :
(defadvice kill-emacs (around emacs-immortal) nil)
(ad-activate 'kill-emacs)
Use ad-deactivate to deactivate this trick.
Within emacs-clients, save-buffers-kill-terminal only calls server-save-buffers-kill-terminal, so you might want to install an advice onto that to not affect non-client frames. The frame-list function cal be used to introspect the currently existing frames. It apparently always includes one entry for the daemon process itself, and then one for each open frame.
(defadvice server-save-buffers-kill-terminal (around dont-kill-last-client-frame activate)
(when (< 2 (length (frame-list)))
ad-do-it))
I've been searching for how to restore an emacs session, with no luck. I'm looking to restore all previously open buffers, some of which might contain erc, shells, directory listings, files, etc.
Every time I open emacs, I spend a considerable amount of time arranging my buffers; splitting them into rows and columns, opening a shell, arranging irc channels. It takes a while to get onto work.
I've tried adding the following to my init.el
(desktop-save-mode 1)
And then using M-x desktop-save. This only seems to restore files that are open, not shells or anything else running within buffers.
I've also checked the following questions:
Session management in emacs using Desktop library
Emacs session / projects / window management
Emacs: reopen buffers from last session on startup?
And read through:
DeskTop and EmacsSession at emacsWiki.org
Here's a screenshot example of my emacs session.
A simple answer would be to just focus on real work :P
I'd suggest a simple solution - create a function that sets up your preferred layout. For example I like to have some IRC channels in the second half of my screen in separate windows, so that I may have a look at them from time to time, while coding for instance in another window. So I've written some simple code to take care of the window splitting and arrange my buffers as I wish:
;; show some buffers
(defun show-some-buffers (buffer-list)
(split-window-horizontally)
(other-window 1)
(dolist (buffer buffer-list)
(split-window-vertically)
(switch-to-buffer (get-buffer buffer))
(other-window 1))
;; at the end we have one extra window we need to delete
(delete-window)
(balance-windows))
;; show some erc buffers
(defun show-erc-buffers ()
(interactive)
(show-some-buffers '("#emacs" "#clojure")))
The code is fairly simple and features no error checking, but it will give you a hint about what I mean.
You might want to consider using registers as well to store some window configurations.
As you've found, desktop.el and session.el are a good start, but they don't restore the window layouts.
However, using revive.el you can save/restore arbitrary window configurations, which are remembered between restarts.
Also check out these hints relating to window layouts, which cover winner-mode and the trick of saving window configurations into registers.
In addition to #Bozhidar's excellent answer on automating your window layout (which I do myself), you may also want to look into using GNU Screen which can be used to retain an arbitrary set of processes across log ins. There's a pretty good tutorial here, and since you'll be using emacs you'll also want to give this a read.
I'm looking for a way to send the output of an arbitrary Emacs command (in my case sql-send-region) to another window. I would prefer to maintain focus in the window I am currently in, which would effectively give me one window to edit queries and one window to view the output.
I was able to write some Emacs Lisp to solve my problem:
(defun sql-send-region-and-return (start end)
(interactive "r")
(let ((oldbuf (buffer-name)))
(sql-send-region start end)
(switch-to-buffer oldbuf)))
This sends the result of your region to the SQL buffer and returns back to your current buffer, effectively accomplishing the stated objective.
Thanks justinhj for giving me some new leads to solve my problem.
Have you tried setting this variable to t, it sounds like the behaviour you want.
sql-pop-to-buffer-after-send-region
After a call to sql-send-region' orsql-send-buffer',
the window is split and the SQLi buffer is shown. If this
variable is not nil, that buffer's window will be selected
by calling pop-to-buffer'. If this variable is nil, that
buffer is shown usingdisplay-buffer'.
I'm using pdb to debug Python programs and am unhappy with it's behaviour.
I have the screen divided into multiple emacs windows, and when I execute pdb, it (randomly?) replaces one of the windows with the output of the *gud* debugger.
Also, when a breakpoint is encountered, even if the debugging buffer is already visible in a window, it usually puts this buffer into another window, and replaces another of my windows with the contents of the source file. (incidentally I like that it jumps to the correct line in the source file)
How can I disable gud/pdb from managing my windows for me? Is it possible in emacs to prevent all programattic manipulation of windows & screen layout?
Edit: I found the answer that partially solves this in another post: toggle dedicated windows
I tried all these approaches without success on Emacs 24.
If you are still interested I reverted to the old gdb behavior using 'gud-gdb' which implements 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
Look into sticky windows.
I have a solution that prevents the gdb from stealing windows. It works with Emacs 24.4 (2014-07-18 snapshot) and does not require dedicating buffers. The benefit over other answers is you won't have to bother dedicating and undedicating buffers whenever you change buffers, which quickly becomes tedious.
Place this advice in your .emacs:
(defadvice gdb-inferior-filter
(around gdb-inferior-filter-without-stealing)
(with-current-buffer (gdb-get-buffer-create 'gdb-inferior-io)
(comint-output-filter proc string)))
(ad-activate 'gdb-inferior-filter)
This effectively replaces this function as defined in gdb-mi.el and removes the branch that calls gdb-display-buffer, which is the cause of the window thievery.
You should use Sticky Windows to make your windows and buffers stick where they are but Sticky Windows won't stop gud/pdb from trying to steal your windows. When gud/pdb can't steal your source code window, it opens a new Emacs Frame even if there is another window on the current frame.
This comes from the fact that the function that tries to jump to the gud-pdb buffer (py-pdbtrack-track-stack-file) calls function pop-to-buffer with argument OTHER-WINDOW set to t.
To circumvent this behavior for all libraries that calls pop-to-buffer, you could cancel the role of OTHER-WINDOW by defining an advice on pop-to-buffer (in your .emacs) :
(defadvice pop-to-buffer (before cancel-other-window first)
(ad-set-arg 1 nil))
(ad-activate 'pop-to-buffer)
You should also customize variable pop-up-windows to nil in order to force display-buffer (the low-level routine used to display a particular buffer on windows and frames) to not create a new window.
For my day job, I live in Emacs. Utterly. I also have become pretty dependent on CScope to help me find things in the code.
Normally, I have 2 windows in a split (C-x 3):
alt text http://bitthicket.com/files/emacs-2split.JPG
And I use the right window for code buffers and the left window for the CScope search buffer. When you do a CScope search and select a result, it automatically updates the right-side window to show the buffer referred to by the result. This is all well and good, except that it causes me to lose my place in some other buffer that I was studying. Sometimes this is no biggie, because [C-s u] gets me back to where I was.
What would be better, though, is to have 3 split windows like this ([C-x 2] in the left window):
alt text http://bitthicket.com/files/emacs-3split.jpg
And have the bottom left window contain the CScope search buffer, and the top left window be the only buffer that CScope ever updates. That way, I can see my CScope searches and navigate around the code without losing the buffer I'm focused on.
Anyone know how I can do that?
Put this in your .emacs file:
;; Toggle window dedication
(defun toggle-window-dedicated ()
"Toggle whether the current active window is dedicated or not"
(interactive)
(message
(if (let (window (get-buffer-window (current-buffer)))
(set-window-dedicated-p window
(not (window-dedicated-p window))))
"Window '%s' is dedicated"
"Window '%s' is normal")
(current-buffer)))
Then bind it to some key - I use the Pause key:
(global-set-key [pause] 'toggle-window-dedicated)
And then use it to "dedicate" the window you want locked. then cscope can only open files from its result window in some OTHER window. Works a charm. I specifically use it for exactly this purpose - keeping one source file always on screen, while using cscope in a second buffer/window, and looking at cscope results in a third.
Well, I decided to not be a reputation-whore and find the answer myself. I looked in cscope.el as shown on the Emacs wiki, as well as the xcscope.el that comes with the cscope RPM package on RHEL.
Neither appear to give a way to do what I'm wanting. The way is probably to edit the ELisp by adding a package variable like *browse-buffer* or something and just initialize that variable if not already initialized the first time the user does [C-c C-s g] or whatever, and always have the resulting code shown in *browse-buffer*. Then the user can put the *browse-buffer* wherever he wants it.