[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18923: Alternative scrolling model
From: |
Eli Zaretskii |
Subject: |
bug#18923: Alternative scrolling model |
Date: |
Sun, 02 Nov 2014 18:31:08 +0200 |
> From: E Sabof <esabof@gmail.com>
> Cc: 18923@debbugs.gnu.org
> Date: Sun, 02 Nov 2014 16:21:23 +0000
>
> > What are the advantages of this alternative way of scrolling, beyond
> > being in Lisp and eliminating the jumps when encountering an image?
> > (Btw, a test case for the latter would be nice, perhaps as a separate
> > bug report.) If the only advantage is better handling of in-line
> > images, then perhaps fixing the existing implementation is a better
> > path forward?
>
> There aren't. Do you have ideas on how this could be accommodated? Technically
Sorry, I'm not sure I understand the question. If you mean how to
avoid jumps with the existing C implementation when there are inline
images, then please show a recipe to see the problem, and let's take
it from there.
> >> (defun st-height (&optional pos)
> >> "Won't report accurately, if the line is higher than window."
> >> (cl-flet (( posn-y ()
> >> (cdr (posn-x-y (or (posn-at-point)
> >> (progn
> >> (vertical-motion 0)
> >> (set-window-start nil (point))
> >> (posn-at-point)))))))
> >
> > Did you try using pos-visible-in-window-p? I think it's what you
> > want.
>
> Reading through the documentation of `pos-visible-in-window-p' didn't suggest
> how it could be useful.
Do you still not understand that? If so, I will elaborate why I think
that function is what you want.
> A more descriptive name for the function would be
> `st-get-pixel-height-of-line-at-point'.
Yes, I think I understood that.
> >> (cl-loop do (push (st-height) rows)
> >> until (or (zerop (vertical-motion direction))
> >> ;; >= ?
> >> (>= (cl-reduce '+ rows)
> >> (abs ammount))))
> >
> > I don't understand why you needed this loop. Can't you use
> > window-body-height instead?
>
> What I need mostly depends on the amount of pixels I want to scroll - (for 2
> "normal" lines, this loop would run twice) which is usually less than
> window-body-height, but could potentially be more.
IME, the most important use case is scrolling by "almost the full
window", in which case it is better to start with window-body-height
and subtract from it, instead of starting with zero and add to it.
The most expensive part here is vertical-motion, so I think you want
to call it as little as possible.
> > This doesn't support the equivalent of a nil argument, which means
> > move by "near full screen".
>
> I can implement this if the overall approach gets a green light.
I think we need to decide first whether the slowdown is acceptable.
IMO it is too significant to be ignored, if we want to replace
existing code.
bug#18923: Alternative scrolling model, Eli Zaretskii, 2014/11/02
- bug#18923: Alternative scrolling model, Stefan Monnier, 2014/11/02
- bug#18923: Alternative scrolling model, E Sabof, 2014/11/02
- bug#18923: Alternative scrolling model,
Eli Zaretskii <=
- bug#18923: Alternative scrolling model, E Sabof, 2014/11/02
- bug#18923: Alternative scrolling model, Eli Zaretskii, 2014/11/02
- bug#18923: Alternative scrolling model, E Sabof, 2014/11/02
- bug#18923: Alternative scrolling model, Eli Zaretskii, 2014/11/02
- bug#18923: Alternative scrolling model, Eli Zaretskii, 2014/11/02
Message not available