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.
Related
Any movement commands cause the eldoc-message in the minibuffer to flicker. Disabling evil-mode eliminates the flicker.
From the eldoc documentation, I found this relevant snippet.
;; This function goes on pre-command-hook for XEmacs or when using idle
;; timers in Emacs. Motion commands clear the echo area for some reason,
;; which make eldoc messages flicker or disappear just before motion
;; begins. This function reprints the last eldoc message immediately
;; before the next command executes, which does away with the flicker.
;; This doesn't seem to be required for Emacs 19.28 and earlier.
(defun eldoc-pre-command-refresh-echo-area ()
(and eldoc-last-message
(if (eldoc-display-message-no-interference-p)
(eldoc-message eldoc-last-message)
(setq eldoc-last-message nil))))
How do I prevent the flicker with evil-mode enabled?
So, evil-mode is innocent. The culprit is key-chord.el.
The display flickers when a key is pressed that was present in key-chord-define. I had "jk" bound to keyboard-quit, so every time I pressed j or k, eldoc would flicker.
(key-chord-define-global "jk" 'keyboard-quit)
This isn't a bug in evil-mode. It's just more noticeable in evil-mode because of the single letter commands like h and j.
I patched key-chord at https://github.com/jschaf/key-chord to fix the flicker. See commit a2f6c61 for the actual fix.
Is it possible to let Emacs have the cursor be moved off-screen, like most GUI text editors work? This is one of the biggest things that bothers me when I use Emacs over any GUI editor. When I scroll down, the cursor is "pushed forward" by the top of the buffer.
I had previously thought that this was completely impossible, because this is hard-wired into the architecture of Emacs, but then I saw multiple-cursors, which does exactly this for the secondary cursors (assuming you prevent the scrolling functions from acting on the secondary cursors). Is it maybe possible to use multiple-cursors to have the main cursor in some hidden buffer, and the effective cursor being what I actually edit with? Or maybe some other clever trick? Or maybe my Googling has failed me and this is really already possible without any magic?
There is a new package available on GNU ELPA called scroll-restore that attempts to remedy this problem. So far, I have encountered a few bugs, but the package seems to work as-advertised for the most part.
You can test it out by installing it with
M-x package-install RET scroll-restore RET
After the package is installed, you can enable the minor mode with
M-x scroll-restore-mode
Personally, I am binding it to the Scroll Lock key because it seems so incredibly apropos! This is what I am adding to my init file:
(require 'scroll-restore)
(scroll-restore-mode 1)
;; Allow scroll-restore to modify the cursor face
(setq scroll-restore-handle-cursor t)
;; Make the cursor invisible while POINT is off-screen
(setq scroll-restore-cursor-type nil)
;; Jump back to the original cursor position after scrolling
(setq scroll-restore-jump-back t)
;; Toggle scroll-restore-mode with the Scroll Lock key
(global-set-key (kbd "<Scroll_Lock>") 'scroll-restore-mode)
This is a direct copy of an answer posted here: https://emacs.stackexchange.com/a/2273/93
Strictly, speaking you can't move the cursor offscreen, because the underlying C code won't let you do it.
This said, I suspect that your problem can be fixed. Basically, there are 2 aspects:
you don't like the way things look when "the cursor is pushed forward". You could work around that by (temporarily) making the cursor invisible.
you want to "jump back" to the pre-scrolling position as soon as you issue a non-scrolling command. There's probably some package out there that does it for you, but you can do it yourself with some pre-command-hook hacking.
BTW, I'd welcome patches in Emacs which provide some of that functionality. I hate the "auto jump-back" behavior of other editors, but it would be good to record the "pre-scroll" position and then offer a way to jump back to it.
Judging by the context and description of your problem, it looks like you want to browse the buffer while preserving your place of editing. There are at least two tricks for that purpose: marks/registers and splitting in two windows.
https://stackoverflow.com/a/3777598/308668 describes the Emacs' registers that act like Vim's marks. You can check in your place in the file with keying C-x r SPC a (a being a letter of your choice) and you can always come back with C-x r j a.
Some sort of automation is achieved by an external script (goto-last-change.el), described here: https://superuser.com/a/184402/49046.
Alternatively, split the window in two with C-x 2. The newly split windows both show the same location and you can use the other to explore. C-x 0 closes a window when you're done.
Every now and then Emacs develops this annoying behaviour of remembering a position in a buffer. Whenever I leave the buffer and return the point automatically moves back to the same position.
I probably hit some random command without being aware of it, but does anyone know what this is and how I can stop it?
I think saveplace is useful in such case.
you add following S-exp in your configuration file.
(load "saveplace")
(setq-default save-place t)
See Also
http://www.emacswiki.org/emacs/SavePlace
One tantalizing shortcoming of Emacs is its weirdly broken scrolling mechanism on 'inertia-scrolling' OSX. After a lot of digging, the real problem seems to be that Emacs only registers keys for mouse wheel scrolling in one, two or three increments, that is wheel-up|down, double-wheel-up|down and triple-wheel-up|down.
However, the Mac trackpad seems to generate far bigger scrolling increments when scrolling fast. So, is there a way to generate more accurate scrolling messages that actually reflect the amount the trackpad was scrolled?
I am running Emacs 24.0.92 from http://emacsformacosx.com/.
Relevant .emacs settings:
(setq redisplay-dont-pause t)
(setq mouse-wheel-progressive-speed nil)
Ultimately, what I would like to have is something like this:
(defun up-single () (interactive) (scroll-up 1))
(defun up-double () (interactive) (scroll-up 2))
(defun up-triple () (interactive) (scroll-up 3))
...
(global-set-key [wheel-down] 'up-single)
(global-set-key [double-wheel-down] 'up-double)
(global-set-key [triple-wheel-down] 'up-triple)
...
I do not understand clearly what you want, but while Emacs only has distinct event names for single/double/triple clicks, it actually distinguishes up to sequences of 9 clicks. The event-click-count can be used to extract this info from an event.
It seems as if Emacs does not handle scroll events like OSX does. The double- and triple- modifiers and the event-click-count function Stefan mentioned do not signify single events of fast scrolling but merely that several scroll events happend in close succession. So when you begin to scroll, you get a 'click count' of 1, then 2, then 3 and so on.
On OSX, the trackpad does not issue individual scroll events like a mouse-wheel does. Instead, each event contains a pixel increment of how far the cursor moved since the last event. Programs should move their scroll-views by a distance proportional to that increment. However, to my knowledge Emacs scroll events do not contain that increment. Therefore, Emacs in its current form can not implement inertial scrolling.
PLEASE correct me if I'm wrong!
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.)