I like running shell programs using Emacs ansi-term mode, but I wonder how to set the maximum buffer size in ansi-term mode so I won't lose command history even when there are lot of lines? (Google doesn't seem to give a obvious answer.)
The variable term-buffer-maximum-size controls this value. Setting it to 0 should buffer everything (haven't used it but that is what the doc says). I'd be tempted to use a large value instead so a runaway program doesn't cause serious issues. It defaults to 2048 lines.
(setq term-buffer-maximum-size 0)
in your term-mode-hook function should do it.
Related
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.
I have used emacs for erlang programming. According to http://emacswiki.org/emacs/CompileCommand, I have configure c-c c for recompile.
In the emacs frame, 6 windows are open, top 3 are for erlang source code reading and writing.
In the below windows, one is supposed for the compie window.
But when different windows is active and recompile, the compile window will switch randomly. How to fix it in one perticular window?
If you start reading at C-hf display-buffer RET (or in the manual at M-: (info "(elisp) Choosing Window") RET), you'll find a bunch of ways in which you can modify the behaviour.
It can get a little complex, but something like this might be all you need in your recompile function:
(let ((display-buffer-overriding-action
'(display-buffer-reuse-window)))
(compile))
I always use dedicated windows when I want to keep things in the one place, so you might also find that useful to look into:
M-: (info "(elisp) Dedicated Windows") RET
I use the toggle-window-dedicated function from Pin Emacs buffers to windows (for cscope) (see also How do I make this Emacs frame keep its buffer and not get resized?)
I recently added the line
(set-default-font "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1")
to my .emacs file. After that find-file-other-window always opens a new window instead of utilizing existing windows. Why would that happen!? How can I fix it?
I don't understand how all this font-config magic works, so if it's actually obvious I'm sorry.
Edit: I have a pretty large resolution, and my font size has decreased pretty significantly. Does find-file-other-window take into account available character space? Perhaps it's deciding there's sooo much room it can afford to just open windows willy nilly.
find-file-other-window ultimately calls display-buffer, which runs a complex algorithm to decide whether to reuse an existing window or make one and how. In particular, if display-buffer decides it needs to create or recycle a window, it tries calling split-window-preferred-function to split the biggest window. By default, split-window-preferred-function is split-window-sensibly, which is willing to split windows vertically if they are more than split-height-threshold lines high, or failing that horizontally if they are more than split-width-threshold columns wide.
It looks like you want
(setq split-width-threshold nil)
(setq split-height-threshold nil)
N.B. This answer applies to GNU Emacs 23. Earlier versions didn't have horizontal splitting. Later versions may do things differently.
A few ways to find this out (none straightforward):
If you guess that what's going on is called splitting a window: M-x apropos RET split RET shows a number of variables and functions, and you might figure out which ones are relevant. Or if you guess that there's an option (there often is), C-h v split- TAB shows promising leads.
The documentation for find-file-other-window references Displaying Buffers. (You have to go to the Elisp manual for this level of detail; within Emacs, C-h i m elisp RET brings up the Elisp manual, and i find-file-other-window RET leads you to the documentation for this function.) It's less clear that pop-to-buffer is the passage to read there; it references Choosing Window which contains the sought after information.
C-h f find-file-other-window RET shows the built-in documentation for the function. It links to display-buffer. The description of display-buffer doesn't describe its operation in detail, so from there you need to either consult the Elisp manual as above or explore the source of display-buffer by clicking on window.el.
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 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.