How can CIDER REPL be configured so that it only scrolls when that's necessary to show a result?
By default, CIDER REPL (0.18.0) always scrolls the point to the bottom of a window when showing a result, even when there's enough space for it.
I find this jarring. I'm forced to type at the bottom of the window just to prevent "jumps." Ideally, no scrolling should occur in this example. (The point should only scroll to the bottom when a result is longer than the space below the point.)
It looks like this is controlled by the customization variable cider-repl-scroll-on-output:
(defcustom cider-repl-scroll-on-output t
"Controls whether the REPL buffer auto-scrolls on new output.
When set to t (the default), if the REPL buffer contains more lines than the
size of the window, the buffer is automatically re-centered upon completion
of evaluating an expression, so that the bottom line of output is on the
bottom line of the window.
If this is set to nil, no re-centering takes place."
:type 'boolean
:group 'cider-repl
:package-version '(cider . "0.11.0"))
Try changing its value from the default t to nil.
Related
After executing next-error from compilation window the cursor is always positioned in the middle of the page.
How is it possible to change the behavior and have the cursor positioned in the 1/3rd mark of the page?
Dunno why people are advising to advise or redefine next-error, or use a hook. The doc tells you explicitly that you can customize option next-error-recenter, and that its value is passed to recenter.
The choices for the option value are:
No recentering
Center of window
A particular line to recenter to
Try customizing this option.
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!
When I compile (using Make, g++), the compile-buffer opens in a new window, and starts filling up with lines of compiler output. What I don't like is that when the number of lines exceeds the window height, the window doesn't scroll to show the most recent messages at the bottom. Instead it just stays at the top of the buffer, adding the newest messages below the bottom of the window, out of view.
I work around this by switching to the compile window and moving the point to the end of the buffer using M-shift-'>'. Once the point is at the end, it stays there even when additional lines are added, so the bottom-most line stays visible in the window.
How can I automate this behavior, so that compiling not only opens up the compile buffer in a new window, but also moves (that window's) point to the end?
Look into the compilation-scroll-output variable. Instead of just scrolling to the end (setting it to t) I propose 'first-error that scrolls to the first error.
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....
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.