I am new to emacs and I am using evil mode.
When I scroll with j,k and I move out of the screen, emacs will readjust the current line under the cursor to the middle of the screen.
Where can I disable this feature?
By adding the following setting to the .emacs file (or similar user customization file -- e.g., init.el), the user can override the default setting that recenters point as it moves off the screen:
(setq scroll-conservatively 101)
The doc-string for scroll-conservatively, which is visible by typing M-x describe-variable RET scroll-conservatively RET reads as follows (at least in so far as a developer snapshot of Emacs Trunk goes, that is):
"If the value is greater than 100, redisplay will never recenter point, but will always scroll just enough text to bring point into view, even if you move far away. A value of zero means always recenter point if it moves off screen."
Related
if I eval
(with-current-buffer "xx"
(goto-char(point-max)))
when the buffer xx is buried, point is NOT moved after I
switch to it.
it's driving me crazy after sifting my code for a
bug for 5 days only to find it isn't one but a maddening
behaviour I can find no documentation for nor search results relating to.
You moved point to where you wanted in that buffer, but not in any window. The buffer in question need never be displayed. with-current-buffer lets Lisp code do stuff in a buffer. You're confusing window-point with point.
Try this, to see the difference, assuming that your buffer xx is displayed in some visible window on some frame (or use t instead of visible if it's in an invisible window):
(with-current-buffer "xx"
(goto-char 5000)
(message "PT: %S, WINDOW PT: %S"
(point)
(window-point (get-buffer-window "xx" 'visible))))
You can use function set-window-point to set the window-point. See the Elisp manual, node Window Point.
from a reading of the source it appears emacs keeps a list of previously seen buffers per window (window-prev-buffers) recording the cursor position that prevailed at the time of last viewing.
switch-to-buffer, the standard way of raising a buffer, consults switch-to-buffer-preserve-window-point in deciding whether to restore this saved cursor position when a previously seen buffer is revisited by a window.
by setting the variable to nil the buffer's actual point is used as the window point.
this gets the behaviour I want although the variable is not consulted on a buffer local basis so setting has to be global (or local to the buffer one happens to be switching from!) which is undesirable since I can't say there are no alternate universes out there where it's useful for a window and buffer to not agree on where the cursor is.
I am trying to test if a certain position of an Emacs window is visible thus is neither overlapped by another window nor somehow obscured by decoration facilities. To this end I set the mouse position to a certain point and then compare the set values to (mouse-position). However, I get somewhat different values.
How does the actual (mouse-position) differ from the set value?
(Provided that mouse is not moved by the user, indeed).
To test it quickly C-x C-e
(list (set-mouse-position (selected-frame) 4 4) (mouse-position))
As for pos-visible-in-window-p, this does not perform an actual test. To see this
(progn (sleep-for 5) (pos-visible-in-window-p 1))
with C-u C-x C-e and lower, hide the window. Alas, it still is true.
It would seem that pos-visible-in-window-p should do what you want.
Note that your expression moves the actual mouse pointer, i.e., it is visible to the user.
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.
I've started coding on a 30 inch monitor and am wondering if it's possible to move the minibuffer to the top of the screen in emacs? google searches aren't showing up anything.
Cheers
Nimai Etheridge
Have a look at the documentation for the default-minibuffer-frame and initial-frame-alist vars. It sounds like you may be able to have a separate frame for your minibuffer (which you could position at the top of the screen), and then generate minibufferless frames which utilise it.
Note that in initial-frame-alist it states that "If the value calls for a frame without a minibuffer, and you have not created a minibuffer frame on your own, a minibuffer frame is created according to minibuffer-frame-alist", which sounds like exactly what would be needed.
There are ways of saving and restoring frame configurations, so if this worked you could probably recreate the layout automatically when emacs starts.
Edit:
Very basic example/proof-of-concept below for using this frame arrangement. The minibuffer frame can't be deleted until the frames utilising it have been deleted. You'll run into trouble when you do things like maximising the editor frame, of course, so there would certainly be some work to do to try to make this system work in a more seamless fashion.
(setq default-minibuffer-frame
(make-frame
'((name . "minibuffer")
(width . 80)
(height . 1)
(minibuffer . only)
(top . 0)
(left . 0)
)))
(setq new-frame
(make-frame
'((name . "editor")
(width . 80)
(height . 30)
(minibuffer . nil)
(top . 50)
(left . 0)
)))
Naturally, you can also combine this with scottfrazer's method of moving the modeline to the top.
This could possibly be handled in the window-setup-hook?
You should also look at the built-in frame.el and dframe.el libraries. Functions like dframe-reposition-frame may provide a convenient way of keeping the minibuffer frame 'attached' to the top of the active editing frame.
The variable minibuffer-auto-raise can also be configured to raise the minibuffer frame whenever the minibuffer is activated, which may mitigate the need to have it visible the rest of the time.
I'm pretty sure you can't move the minibuffer itself, but you can sort-of-ish make the mode line be on top:
(setq-default header-line-format mode-line-format) ; Copy mode-line
(setq-default mode-line-format nil) ; Remove mode-line
This will override things like Info that use the header line, but it's probably as close as you'll get without hacking C source.
Use a standalone minibuffer frame. This shows how:
http://www.emacswiki.org/emacs/Dedicated_Minibuffer_Frame
http://www.emacswiki.org/emacs/oneonone.el
Either look at that code to get an idea or just use it directly. You need only customize the minibuffer frame position settings:
1on1-minibuffer-frame-left -- Position of left edge of minibuffer frame, in pixels.
1on1-minibuffer-frame-top/bottom -- Position of top (or bottom) of minibuffer frame, in pixels.
After being stuck on these answers for a good while, I discovered clemera's answer for emacs 26+ to be useful:
For Emacs 26 and later you can use emacs-maple-minibuffer or ivy-posframe if your are using ivy.
Those packages let you configure to popup a minibuffer frame at any position, including the current window top/bottom. The docs of those packages describe how to set them up.
Is there a way to scroll through a document without exiting isearch mode? I have isearch-allow-scroll set to t, but that limits my scroll range to make sure the current isearch match is visible in the buffer. Ideally, I would like to be able to scroll with the mousewheel, having all the isearch matches highlighted as I scroll.
I am aware of M-x occur, but a lot of the time simply being able to scroll in isearch mode would be more efficient (in addition, M-x occur does not play well with folding mode).
There's also highlight-regexp if you want. It will highlight regexps and you can scroll as usual.
It looks like what you want is not possible in general. From the documentation inside isearch.el:
;; scrolling within Isearch mode. Alan Mackenzie (acm#muc.de), 2003/2/24
;;
;; The idea here is that certain vertical scrolling commands (like C-l
;; `recenter') should be usable WITHIN Isearch mode. For a command to be
;; suitable, it must NOT alter the buffer, swap to another buffer or frame,
;; tamper with isearch's state, or move point. It is unacceptable for the
;; search string to be scrolled out of the current window. If a command
;; attempts this, we scroll the text back again.
In other words, it's not possible to scroll far enough that the search string moves out of the window.
Try Icicles search -- for example, icicle-occur (bound to C-' in Icicle mode).
Nothing prevents you from scrolling as far as you like with the mouse etc.
Icicles search is a different kind of incremental search. icicle-occur is like an incremental occur: as you edit your input in the minibuffer the lines are filtered by that input.
Search hit candidates are completion candidates (e.g., appear in *Completions*). You can navigate among hits in the searched buffer using C-down, or you can jump directly using C-RET or C-mouse-2.