Scroll can take a very long time if going a long distance about sublimity

[zk-phi]

• annoying scroll speed

scroll speed is faster, when you are traveling longer distance. this is already the normal behavior of sublimity.
because scroll speed depends on environments, it is also configurable. the variable "sublimity-scroll-weight1" is especially important for very long buffers. please read README.org for more informations.

• inertial scroll

sublimity is not a scroll command. to implement such features, emacs-native commands "scroll-down" "scroll-up" are perhaps not enough. i have never tried, but you may find an inertial scroll package for Emacs as an demonstration of deffered.el.

http://www.emacswiki.org/emacs/InertialScrolling

i'm not planning to implement such feature in sublimity, at least for now.

thanks.

[mathrick]

scroll speed is faster, when you are traveling longer distance. this is already the normal behavior of sublimity.
because scroll speed depends on environments, it is also configurable. the variable "sublimity-scroll-weight1" is especially important for very long buffers. please read README.org for more informations.

I know it exists, but the whole problem is that the speed is not big enough for long distances. You can do it easily by comparing directly against Sublime. I have it open on the exact same text, my package list, which is 2600 lines long. If I go to the top of the buffer in Sublime Text, and press first PgDn, then C-End, both scrolls will take the same time. Scroll by a page is visibly much slower, whereas scroll to the end whisks past almost all of the buffer at a much greater speed, and even though it slows down at the end, it's still much faster than the max speed a scroll by page ever reaches. The end result is that while the distance covered is much different, their speeds are adjusted in a way that makes the time spent on it constant, and the second scroll is visibly much faster, as it should be.

That is not the case if you do the same in sublimity. The scroll by page is much faster than in Sublime Text (defeating the point of having smooth scroll in the first place), whereas scroll to end is much slower. And that's with sublimity-scroll-weight1 already reduced to 5, much lower than the initial 10. The algorithm simply doesn't do the right thing, because the scaling it uses should result in a constant time spent on a single scroll regardless of the distance, and that doesn't happen right now.

sublimity is not a scroll command. to implement such features, emacs-native commands "scroll-down" "scroll-up" are perhaps not enough. i have never tried, but you may find an inertial scroll package for Emacs as an demonstration of deffered.el.

Ah, well, that's a pity.

[zk-phi]

thanks for the response. now i understand the problem.

here's another algorithm i'm trying, which is perhaps not perfect but in usable condition.

(defcustom sublimity-scroll-weight 8
  "scroll is maybe divided into N small scrolls"
  :group 'sublimity)

(defun sublimity-scroll--gen-speeds (amount)
  (let (a lst)
    (flet ((fix-list (lst &optional eax)
                     (if (null lst) nil
                       (let* ((rem (car lst))
                              (val (floor rem))
                              (rem (+ (- rem val) (or eax 0)))
                              (val (if (>= rem 1) (1+ val) val))
                              (rem (if (>= rem 1) (1- rem) rem)))
                         (cons val (fix-list (cdr lst) rem))))))
     (cond ((integerp sublimity-scroll-weight)
            (setq sublimity-scroll-weight (float sublimity-scroll-weight))
            (sublimity-scroll--gen-speeds amount))
           ((< amount 0)
            (mapcar '- (sublimity-scroll--gen-speeds (- amount))))
           (t
            ;; x = a t (t+1) / 2 <=> a = 2 x / (t^2 + t)
            (setq a (/ (* 2 amount)
                       (+ (expt (float sublimity-scroll-weight) 2)
                          sublimity-scroll-weight)))
            (dotimes (n sublimity-scroll-weight)
              (setq lst (cons (* a (1+ n)) lst)))
            (remove-if 'zerop (sort (fix-list lst) '>)))))))

does it work ? it seems not very smooth but scroll ends in (almost) constant time.

[zk-phi]

found a reasonable solution and updated sublimity-scroll.el.
thanks