emacs 23.2
I have just installed emacs on a 10.1" screen netbook.
However, when I compile my source code the compilation window always opens in a horizontal buffer below my source code buffer.
At work I use a 15" screen and the compilation opens up in a vertical window, which is what I like.
However, on my 10.1", is there any way to force it to open in a vertical window. Its just easier to scroll down and find errors when you have the source code buffer vertical to the compilation buffer.
Many thanks for any advice,
Related question here.
(defadvice compile (around split-horizontally activate)
(let ((split-width-threshold 0)
(split-height-threshold nil))
ad-do-it))
If you always want to split horizontally when a new buffer is displayed, you can just set the two variables above and dispense with the advice.
Try these settings:
(setq split-height-threshold nil)
(setq split-width-threshold 0)
With respect to needing to scroll down the source code, you should check out C-x ` or M-x next-error and let Emacs do the scrolling for you.
Take a look at the section "Choosing a window to display" in the Emacs manual. In particular,
Option split-width-threshold
This variable specifies whether split-window-sensibly may split windows horizontally. If it is an integer, split-window-sensibly tries to horizontally split a window only if it has at least this many columns. If it is nil, split-window-sensibly will not split the window horizontally. (It still might split the window vertically, though, see above.)
Related
Often I have multiples windows carefully arranged within a frame.
However, certain command, say M-x man RET will grab one of the visible windows to display its own content. Sometimes this is annoying because the window that was taken away is one that I need to keep it visible.
e.g. I have 3 windows on screen, one useful source-code window and two useless windows. I want to keep the soure-code window visible while checking the man page. But very often Emacs just take away the code-window for the newly opened man page.
One way I can think of is to display the (chronological) open order of each window, so that I can focus point on n-th window and be confident that Emacs will grab (n+1)-th window for new content.
Is there a way to display such order, e.g. in the mode-line of each window?
Or is there another way for better control for displaying new window?
A little late to the party but as discussed in the comments, using dedicated windows is a good way to control where new content is displayed (+1 to #lawlist for bringing it up and to #phils for mentioning toggling!).
I'm pretty sure you'd be able to implement a command that toggles dedicatedness yourself at this point, but since I have the code for this handy I'll share it anyway:
(defun toggle-window-dedicated ()
"Control whether or not Emacs is allowed to display another
buffer in current window."
(interactive)
(message
(if (let (window (get-buffer-window (current-buffer)))
; set-window-dedicated-p returns FLAG that was passed as
; second argument, thus can be used as COND for if:
(set-window-dedicated-p window (not (window-dedicated-p window))))
"%s: Can't touch this!"
"%s is up for grabs.")
(current-buffer)))
(global-set-key (kbd "C-c d") 'toggle-window-dedicated)
Now, in a multi-window setup you can simply press C-c d in each window you would like to "protect".
I'll throw this example usage of display-buffer-alist into the mix, given that it was mentioned in the comments, and is indeed a general mechanism for controlling how and where buffers are displayed (even though, as Drew indicates, it is far from trivial).
Start with the help for the variable itself:
C-hv display-buffer-alist RET
From there you'll get to the help for display-buffer, and no doubt acquire some idea of the complexities involved :)
In any case, the following is an example of using a custom function to decide how to display buffers named *Buffer List*.
You can easily see that if you can write a function which can figure out how to display a buffer where you want it to, then you can use display-buffer-alist to make it happen.
(defun my-display-buffer-pop-up-same-width-window (buffer alist)
"A `display-buffer' ACTION forcing a vertical window split.
See `split-window-sensibly' and `display-buffer-pop-up-window'."
(let ((split-width-threshold nil)
(split-height-threshold 0))
(display-buffer-pop-up-window buffer alist)))
(add-to-list 'display-buffer-alist
'("\\*Buffer List\\*" my-display-buffer-pop-up-same-width-window))
A key quote regarding the ACTION functions is:
Each such FUNCTION should accept two arguments: the buffer to
display and an alist. Based on those arguments, it should
display the buffer and return the window.
It is possible to "scroll past the end of the buffer" in a window. This is useful because Emacs has to somehow use the extra space when the buffer does not fill the whole area available to the window used to display it.
However sometimes when the whole buffer would fit completely into the window the top part still isn't displayed and more space than necessary is wasted below the buffer content to fill the available space. It would be better if the window were automatically scrolled to show the complete buffer or if it is bigger than the window as much as possible.
In other words the only time when a window displays something "below the buffer end" is when the window is to big.
Is there a mode or option to do that?
Edit: So something like this?
(add-hook 'post-command-hook 'my-eob-recenter)
(defun my-eob-recenter ()
(when (pos-visible-in-window-p (point-max))
(save-excursion
(goto-char (point-max))
(recenter -1))))
Original answer:
If you have a window which is larger than its contents and you want to shrink it to fit, there's a binding for that.
C-x- runs shrink-window-if-larger-than-buffer
Personally I suspect this would be annoying if it happened automatically, but you might try this:
(defadvice split-window (after my-split-window-shrink)
"Shrink the selected window after a window split
if it is larger than its contents."
(shrink-window-if-larger-than-buffer))
(ad-activate 'split-window)
I am getting problem with autoscrolling with next-line in emacs. When i get to the edge of the screen
http://i.stack.imgur.com/lfqEL.png
and making next-line sometimes I am not scrolled, and pointer aims to the center of the CURRENT screen, not the NEXT screen. http://i.stack.imgur.com/FPbuC.png
(so if i hold C-n pointer will run endlessly through this screen)
I am getting same things with forward-line, sometimes with forward-page. I am not getting the same with previous-line autoscrolling, it works fine.
I don't know why. I only noticed, that when I have more long lines, and screen is splited vertically, this thing happens very fast(C-x 3 C-x 3, scrolling from the beginning of my 1000-lines .emasc file is a fast way to reproduce this bug).
Emacs -Q, (setq truncate-lines nil) doesn't have it. Emacs, (setq truncate-lines t) doesn't have it too.
If you know anything about what can cause this troubles, please reply.
One potential source for this issue seems to be setting the scroll-conservatively variable.
http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/0a7a9c730c037d57
I noticed that when moving down through big files, sometimes the
cursor will jump from bottom of screen to middle.
Any idea why this would happen only some of the time?
Because Emacs' redisplay is unable to keep with the scrolling. Before
23.1, with scroll-conservatively set to a large value, Emacs never
jumped; now it tries no to do it, but sometimes it fails. I think the
relevant ChangeLog entry is this one:
2008-10-27 Chong Yidong
* xdisp.c (try_scrolling): When computing the distance from the
scroll margin to PT, try moving some distance past the window
bottom before giving up.
Juanma
After 2-hour using eval-region (this problem wasn't easy to reproduce, macro/elisp with (next-line) (sit-for 0.01) didn't give any effect, so I tested it each time by holding C-n, using binary search method for eval-region)
So the answer is:
http://www.emacswiki.org/emacs/HighlightParentheses
Evaluating this in a *scratch*, starting emacs with emacs -Q
(setq-default truncate-lines nil)
(setq truncate-partial-width-windows nil)
(add-to-list 'load-path "~/my_path_to_highlight-parentheses_script/")
(require 'highlight-parentheses)
Make some buffer with long lines and narrow it with C-x 3 C-u 5 0 C-x } then C-x o M-x highlight-parentheses-mode and hold C-n is a way to reproduce the bug.
I commented out all thing relative with highlight-parentheses, and bug gone away. I think, I should find a way to tell developers about this bug.
my Lisp-working-environment has the frame split into two windows, the former for the main coding, the latter for my slime evaluation.
Unfortunately, when I made some mistakes (cause I'm still learning Lisp :P) the slime debugger warns me, and doing this it shows up into the bottom window that is automatically resized.
Just to be more explicit:
BEFORE:
_______
| |
| |
_______
|_____|
AFTER:
_______
| | <- decreased in size!
_______
|_____| <- increased in size!
How can I prevent Emacs resizing my windows? I want Emacs to leave my window sizes the same.
How can I accomplish that?
Thanks! Bye!
Alfredo
You can remember your window configuration using the command M-x window-configuration-to-register (or C-x r w) at the beginning.
After you can always restore your configurations using M-x jump-to-register (or C-x r j).
winner-mode is a lifesaver, but to make pop-to-buffer not resize the window in the first place, do
(setq even-window-heights nil)
Unfortunately the main command pop-to-buffer, which is used by almost every program in emacs to switch to a buffer in a different window, has the side-effect you described.
In adition to all other solutions so far, there is a winner mode to undo/redo any changes in window configuration, at any moment of time.
If some code you call changes the window configuration you can
wrap your code with (save-window-excursion BODY ...)
If it is the debugger that changes the configuration - hit "q" and the old configuration will be resotred.
If you want the debugger not to change size try adding a debugger-mode-hook to restore your window size.
To disable window shrinking, shrink-window-if-larger-than-buffer needs to be a no-op. You could just redefine it to do nothing, but if you advise it, you get the ability to enable and disable it at will.
;; never shrink windows
(defvar allow-window-shrinking nil
"If non-nil, effectively disable shrinking windows by making `shrink-window-if-larger-than-buffer' a no-op.")
(advice-add 'shrink-window-if-larger-than-buffer
:before-while
(lambda (&rest args)
"Do nothing if `allow-window-shrinking' is nil."
allow-window-shrinking))
You can advise other functions that call shrink-window-if-larger-than-buffer to enable or disable shrinking:
(advice-add 'some-function-that-resizes-windows
:around
(lambda (orig &rest args)
"enable shrinkage"
(let ((allow-window-shrinking t))
(apply orig args))))
I had an old piece of code that was essentially the above, and I had ignore-errors wrapped around (apply orig args) for some forgotten reason, but it probably isn't universally needed.
N.B. this uses the new advice API, which was added in Emacs 24.4. The old advice API can do the same thing with different syntax if you need to use an old Emacs version.
Set the 'frame-inhibit-implied-resize' variable to 'true' [1], either via the configuration file (~/.emacs etc.):
(custom-set-variables '(frame-inhibit-implied-resize t))
or via the GUI with:
Options > Customize Emacs > Specific Option > 'frame-inhibit-implied-resize' > Value Menu = 'Always' & Apply and Save
In case of the latter method the 'STATE' in the 'Customize Option: Frame Inhibit Implied Resize' buffer should indicate 'SAVED and set', as opposed to 'STANDARD'.
From [1]:
"If {Frame Inhibit Implied Resize} is nil, setting font, menu bar, tool bar, internal borders, fringes or scroll bars of a specific frame may resize the frame in order to preserve the number of columns or lines it displays. If this option is t, no such resizing is done. (..)"
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.