Emacs version I am using:
GNU Emacs 22.2.1 (i386-redhat-linux-gnu, GTK+ Version 2.12.9)
Invoking gdb from emacs breaks the horizontal scrolling in emacs windows. I invoke gdb by entering M-x gdb and then accept the default (only adding name of my binary at the end, e.g.):
gdb --annotate=3 unittest
At some point after the debugger is invoked (not immediately), the automatic horizontal scrolling no longer works.
By automatic horizontal scrolling I mean that the expected behaviour is: follow the cursor, shifting the viewport left or right when necessary. For example: when the cursor is positioned at the end of a long line (say column 200) the viewing area of the window is moved to the right, such that column 200 is visible. If I then press 'Home' and the cursor jumps to beginning of line - the window also follows it and I can see the left-most column of the buffer.
Pasting my entire .emacs file here is probably a bad idea so I just searched for entries related to hscroll:
(custom-set-variables
'(column-number-mode t)
'(cua-mode t nil (cua-base))
'(hscroll-global-mode t nil (hscroll))
'(hscroll-margin 5)
'(hscroll-mode-name " ")
'(hscroll-snap-threshold 30)
'(indent-tabs-mode nil)
...
... but I can attach it here or email it if anyone thinks it is needed...
Hope someone knows how to fix this as coz it's a real pain - every time I use the debugger I need to restart emacs... I am pretty sure this problem was not present in version 20....
Related
I use emacs for pretty much everything I can, including running SQL command-line sessions in a shell-mode buffer.
SEEKING:
Make the SQL result-set header (column names) appear at the top of the visible portion of the window even when the actual header from the SQL client output has scrolled out of view.
Further, make the header scroll horizontally to remain aligned with the data columns.
ATTEMPT:
I have been able to wrangle the header-line (via the `window-scroll-functions') such that when the SQL result set header scrolls off the top of the window I set the buffer window's header-line to the SQL result set header.
That effectively keeps the data columns labeled when scrolling vertically, but when scrolling horizontally the header-line does NOT follow the horizontal scroll position (akin to mode-line which also does not normally scroll horizontally, thankfully).
The next thing I wanted to do is have the header-line scroll horizontally as well. So, instead of using `window-scroll-functions' - which does not fire for horizontal scroll [bug???] - I switched to using `post-command-hook' which fires after every command (perhaps overkill no?). This works ... kind-of.
PROBLEM:
Here is the problem, the header-line does not snap into correct position until after an additional command is executed (e.g. "C-e" alone does not cause the header line to snap to, but when followed by "C-b" the snap to happens). It seems like the post-command-hook is being executed AFTER the command, but BEFORE the window is redrawn (which seems kinda weird in the case of commands where the window may be expected to change). Specifically, (window-hscroll) definitely returns the hscroll position as it was BEFORE the command.
CODE:
To avoid clutter, I won't post the actual code I'm using to set the header-line (unless someone is interested in seeing it), but I will post this sample elisp that can demonstrate that the hscroll position has the value from before the command is run:
(defun pch-demo ()
"post-command-hook: Demonstrate that the window hscroll
value is not updated before this hook is run."
(interactive)
;; the following message demonstrates that we are getting the
;; hscroll position as it was PRIOR to running the command
(message "hscroll=%S" (window-hscroll))
)
(add-hook 'post-command-hook 'pch-demo t t)
;; doesn't make much sense with line-wrapping on
;;(setq-default truncate-lines t)
DEMO STEPS:
open a buffer
make sure line truncation is ON
make the window narrow enough (or lines long enough) that some lines get truncated
go to the beginning of a long line and hit C-e
notice that the message says "hscroll=0"
hit C-a
notice that the message says "hscroll=SOMETHING_NOT_EQUAL_TO_ZERO"
QUESTIONS:
1) Is there a better approach (i.e. not using emacs' header-line)? Something from org-mode maybe???
2) Using my approach, does anyone know how I can get the updated window positions in my hook function?
Thanks superbunch!
Occasionally when I'm compiling, I have to scroll up my compilation buffer to see the details of an error. At this point, emacs stops "following" my compilation buffer, i.e., scrolling to automatically display new output.
I'm using Aqumacs on OS X. Any idea how I can "reattach" or re encourage the compilation buffer to follow again?
Regards,
Chris
Put in your ~/.emacs file
;; Compilation output
(setq compilation-scroll-output t)
or even
(setq compilation-scroll-output 'first-error)
to make it scroll to the first error.
Try using M-x auto-revert-tail-mode or M-x auto-revert-mode. Taken from official documentation:
One use of Auto-Revert mode is to
“tail” a file such as a system log, so
that changes made to that file by
other programs are continuously
displayed. To do this, just move the
point to the end of the buffer, and it
will stay there as the file contents
change. However, if you are sure that
the file will only change by growing
at the end, use Auto-Revert Tail mode
instead (auto-revert-tail-mode). It is
more efficient for this. Auto-Revert
Tail mode works also for remote files.
So, as Chmouel already noted, just moving point to end of buffer will also work.
I am not sure about aquamacs but for me (Emacs 23/Debian) I just go in the compilation window and place my cursor at the end of the window which will attach and follow (you can go to another window and it will still follow).
I've recently upgraded from Carbon Emacs (v22.3) to vanilla Emacs 23.2 (from http://www.emacsformacosx.com). On Carbon Emacs when compiling a project, The frame is split in two with the current source file/SConscript in the top window, and the compile output in the bottom window. I'd hit C-x ` to navigate to the first warning or error in the compile output and it would replace whatever was in the top window with the source file the error or warning is in.
In Emacs 23.2, however, a 3rd window is opened causing two windows open in the top half of the frame (split vertically) and the compile output in the window of the bottom half of the frame. How do I tell Emacs to not open a new window and instead open the code in the the existing non-compiler output window in the frame?
A little further clarification on the behavior that I just noticed. If I hit C-x ` while the buffer containing the source file or SConscript file is active, no new window is opened. It's only if I'm manually navigating through the *compilation* buffer and hitting enter on an error or warning, or mouse clicking on a warning when a third buffer window appears.
The function which is used in next-error functionality is pop-to-buffer which in turn uses split-window-sensibly. You can control the behavior of split-window-sensibly by adjusting the variables split-width-threshold and split-height-threshold.
In your case it is split-width-threshold which is too small. In my emacs 23.1 it is set to 160. Just set it to a larger number and the problem should be solved:
(setq split-width-threshold 200)
I can't reproduce this problem myself, but you might try the following:
(setq split-width-threshold nil)
This tells display-buffer never to split windows horizontally, even if they are quite wide. There is also a split-height-threshold variable which is handled similarly. Checking these variables' current values might suggest whether they could be relevant to the behavior you're seeing.
One last thing to check: if you have defined your own display-buffer-function, that could be making these decisions for you.
When I start Emacs, its windows and its minibuffer start up floating on the main frame, leaving a lot of empty space (see: here and here). Any idea of what is going on and how to fix it?
I'm using emacs version 23.1.1 on Xmonad
Thanks!
I get the same thing occasionally when doing a TAB expand in shell mode. I don't end up with an empty mini-buf, it usually has all the contents from the shell expand. The only solution I've found so far is to kill the current shell buffer
You might try C-l (recenter-top-bottom). I've used this over the years as a pretty reliable "repaint" operation that will clear up various detritus that occurs on the frame. It is even more helpful when you do not have a window system.
It looks like an odd interaction between Emacs and your window manager. It's as if Emacs is configuring itself to have a certain number of lines and columns in its active window, but the frame the window manager has allocated it is larger.
Can you try running X without Xmonad (ie. just run startX) and then run Emacs? You won't get frame decorations, but you can still use xterm to start it and see what 'natural' size it gets allocated. With the same Emacs configuration, that would narrow it down to some issue with Xmonad.
It's not obvious from the screenshots, as one is definitely in GUI mode, but the other (green on black) looks like it is in text mode. If you force it to run in text mode (emacs -nw), does it take up the same size? Within the shell, do normal commands take up the entire size of the allocated window?
Are the shell variables COLUMNS or LINES set correctly? Do they match the window dimensions? Assuming you are running bash, is shopt checkwinsize turned on? Do regular commands such as ls wrap at the expected margins and scroll to use the entire window?
It is worth ensuring that text mode is being configured correctly before getting GUI mode to work. I have a hunch the way that Xmonad is managing its window sizing may be the culprit, if it is 'forcing' windows to tile in certain arrangements, and the correct X hints aren't being sent. But - that's all just supposition for now...
This partially works (taken from here):
(defun fullscreen ()
(interactive)
(set-frame-parameter nil 'fullscreen
(if (frame-parameter nil 'fullscreen) nil 'fullboth)))
(add-hook 'emacs-startup-hook 'fullscreen)
The windows get corrected, although the mini-buffer is still larger than the usual.
Sounds like a bug, to me. Consider reporting it: M-x report-emacs-bug. Try to provide a recipe starting from emacs -Q.
I've done this before, years ago, so I know the answer is out there. However the google-space is heavily polluted with namespace collisions, especially new user guides.
This is what I'd like to do in Emacs 21:
Split the screen on a given file buffer (C-x 3).
As I page through the first screen (C-v), the next page of the file is automatically displayed on the second.
To be clear, the next line in the file after the last line on the left screen should be the first line on the right screen, always.
Any help?
You might be looking for follow-mode
It is minor mode that combines windows into one tall virtual window.
You want scroll-all-mode
scroll-all-mode is an interactive compiled Lisp function in `scroll-all.el'.
(scroll-all-mode &optional arg)
Toggle Scroll-All minor mode.
With arg, turn Scroll-All minor mode on if arg is positive, off otherwise.
When Scroll-All mode is on, scrolling commands entered in one window
apply to all visible windows in the same frame.
Set up the windows appropriately, and then turn on scroll-all-mode, and from then on all windows scroll together
If follow-mode doesn't work, you could define your own macro, something like
(defun align-windows ()
(set-window-start (other-window) (window-start))
(scroll-other-window))
Then either use this (along with scroll-down) instead of C-v, or rebind C-v to that, or add
advice to scroll-down.
You can start Follow mode and setting up a basic two-window layout using
M-x follow-delete-other-windows-and-split RET.
it is from http://www.emacswiki.org/emacs/FollowMode