23

I display images in-line with begin_src & result blocks.

However, for large-images, when I scroll past the bottom of the image, I get a 'jerk' and the whole image is scrolled away. Similarly if I scroll up and run into an image, I get a jerk and see the whole image instead of seeing it incrementally bit by bit.

This makes it hard to work with large plantuml/graphviz diagrams in org-mode.

I would like a smooth scoll experience, to gently scroll past the image like in a web browser, without jerking.

I have tried:

(setq auto-window-vscroll nil)

and also

(setq scroll-margin 1
scroll-conservatively 0
scroll-up-aggressively 0.01
scroll-down-aggressively 0.01)

I tried smooth-scroll package and this snippet also.

However, it seems an in-line image only takes up 'one-line' and fixing emacs to scroll only by 'one-line' doesn't fix the issue.

Any solution to this issue?

[edit] Keyboard vs Mouse scrolling:

Mouse scrolling is implied. But keyboard scrolling would be a bonus if proper mouse scrolling would work.

[edit]
Somewhat of a workaround, but useful for working with images in org-mode was to open them in an external app that auto-reloads on file change. Example would be eog (eye of gnome) or shutter or prievew (on OS X). It can be configured via org-file-apps by adding:

extension: \.png\'
Command:   eog "%s"
  • Are you doing keyboard-based scrolling or mouse scrolling? – mankoff Mar 27 '15 at 20:10
  • mouse scrolling, thank you for clarification. – Leo Ufimtsev Mar 27 '15 at 20:11
  • Might require a patch to emacs. I know on of the features/benefits of the Mac-specific port is smooth-scrolling: github.com/railwaycat/emacs-mac-port/blob/master/README-mac But even that is mouse-only. Keyboards move by lines, and images are only one line high... – mankoff Mar 27 '15 at 20:13
  • It'd be nice to have a patch like that... – Leo Ufimtsev Mar 27 '15 at 20:19
  • How about (setq scroll-conservatively 101) and comment out all of your other scroll settings mentioned in the question above and disable that smooth scroll package and/or snippet? The doc-string for scroll-conservatively states: "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." – lawlist Mar 27 '15 at 23:33
7

Since Emacs 26.1, the buffer can be scrolled by individual pixels instead of just lines which can be used to smoothly scroll over images using the mouse wheel. To achieve this I have used the following configuration:

;;; Scrolling.
;; Good speed and allow scrolling through large images (pixel-scroll).
;; Note: Scroll lags when point must be moved but increasing the number
;;       of lines that point moves in pixel-scroll.el ruins large image
;;       scrolling. So unfortunately I think we'll just have to live with
;;       this.
(pixel-scroll-mode)
(setq pixel-dead-time 0) ; Never go back to the old scrolling behaviour.
(setq pixel-resolution-fine-flag t) ; Scroll by number of pixels instead of lines (t = frame-char-height pixels).
(setq mouse-wheel-scroll-amount '(1)) ; Distance in pixel-resolution to scroll each mouse wheel event.
(setq mouse-wheel-progressive-speed nil) ; Progressive speed is too fast for me.

Edit:

I have found that this solution has a few caveats that might be helpful to know:

  • Scrolling over an image higher than the window will still cause the big jarring jump which sees the window scroll until the image is no longer visible (the next line is on the top of the window).
  • You can't make the scrolling instant (less intensive) but yet still scroll by pixels rather than lines.
  • When a new scroll event is issued before the existing animation is finished, the window jumps to the start of the next animation causing a discontinuity in the smooth scrolling.
  • Many people have experienced such a performance degradation using this method that it is just simply not usable. Apparently this is common when some mode line modifications are used.
  • You should not need (require 'pixel-scroll) since pixel-scroll-mode is auto-loaded. – Tobias Jun 21 '18 at 9:33
  • Ah yes, you are right. I was just following the instructions in the documentation string in pixel-scroll.el but I guess they're for a slightly different audience. – Matthew Palermo Jun 21 '18 at 21:22
1

How about this:

;; scroll one line at a time (less "jumpy" than defaults)
(setq mouse-wheel-scroll-amount '(1 ((shift) . 1))) ;; one line at a time
(setq mouse-wheel-progressive-speed nil) ;; don't accelerate scrolling
(setq mouse-wheel-follow-mouse 't) ;; scroll window under mouse
(setq scroll-step 1) ;; keyboard scroll one line at a time
1

The problem as I understand it is that the image is a single line. Changing how scrolling behaves won't solve the problem.

The only solution I am aware of is to slice the image up so that there are technically many shorter images. This can be done using insert-sliced-image.

  • Can you elaborate on the use of insert-sliced-image? Is it possible to override org-toggle-inline-images to first slice these up? – Adam Mar 21 '18 at 3:08
  • You can read about insert-sliced-image by evaluating (describe-function 'insert-sliced-image) -- I don't have any useful elaboration to add to the documentation. I looked through the org-display-inline-images code but I can't understand where the images actually get inserted. I'm sure it's possible to re-write it to use insert-sliced-image, but I don't see how to do it. – Ista Mar 21 '18 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.