[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: move_it_vertically_backward question
From: |
Eli Zaretskii |
Subject: |
Re: move_it_vertically_backward question |
Date: |
Tue, 14 Dec 2021 15:45:53 +0200 |
> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 14 Dec 2021 21:28:44 +0800
>
> > I'm saying that extending an existing primitive to cover your use case
> > might be a better way forward.
>
> I don't know of any existing primitive that may make sense to extend in
> this manner though.
>
> > Which might mean that window-text-pixel-size should support a
> > specification of FROM and TO that is not just buffer position, but
> > something like "beginning of previous line".
>
> Yes, but that would still entail having to repetitively loop in Lisp
> until the desired position is found
No, I meant to ask window-text-pixel-size to do that, by passing it a
specially-formatted value of FROM (and possibly also TO).
> assuming the delta by which we are
> scrolling is larger than the height of the previous screen line, while
> this primitive looks for a line that is at least a specified amount of
> pixels above the window start, which lets us avoid the extra looping in
> Lisp if the line is not tall enough.
So let's teach window-text-pixel-size to be able to accept the FROM
argument which says "N pixels above position POS".
> Also, for the result to be useful, `window-text-pixel-size' would also
> have to return the buffer position of the measured line's start, which
> doesn't make sense for a function that is only intended to measure size.
What makes sense is what we decide that will make sense. We have a
lot of functions that normally return a simple value, but if asked
nicely return additional information. A random example:
pos-visible-in-window-p.
> > So to move back, you need first go far enough back (e.g., with
> > move_it_vertically_backward), then move forward to find the place
> > where you wanted to find yourself wrt the starting point. Se an
> > example in move_it_by_lines.
>
> Thanks. Something like this seems to work:
>
> while (-it.current_y < pix)
> {
> last_y = it.current_y;
> move_it_by_lines (&it, -1);
> }
That's not very efficient if PIX can be a large value.
> But I have a few questions: what is TRT if `move_it_by_lines' can't move
> further back?
Why cannot it?
> And also, does `move_it_by_lines' (or for that matter,
> the move_it_* functions in general) only move within the accessible
> portion of the buffer, or does narrowing have to be handled in some
> specific manner?
The former. In general, very little code in Emacs accesses buffer
text outside of the current restriction; the display code in its
entirety certainly doesn't. You need to manually widen the buffer to
do so. One of the few exceptions is the display-line-numbers feature,
in one of its optional formats of displaying line numbers, where the
user _wants_ it to ignore the narrowing.
- move_it_vertically_backward question, Po Lu, 2021/12/12
- Re: move_it_vertically_backward question, Eli Zaretskii, 2021/12/13
- Re: move_it_vertically_backward question, Po Lu, 2021/12/13
- Re: move_it_vertically_backward question, Eli Zaretskii, 2021/12/14
- Re: move_it_vertically_backward question, Po Lu, 2021/12/14
- Re: move_it_vertically_backward question,
Eli Zaretskii <=
- Re: move_it_vertically_backward question, Po Lu, 2021/12/14
- Re: move_it_vertically_backward question, Eli Zaretskii, 2021/12/14
- Re: move_it_vertically_backward question, Po Lu, 2021/12/14
- Re: move_it_vertically_backward question, Eli Zaretskii, 2021/12/15
- Re: move_it_vertically_backward question, Po Lu, 2021/12/15
- Re: move_it_vertically_backward question, Po Lu, 2021/12/14
- Re: move_it_vertically_backward question, Po Lu, 2021/12/15
- Re: move_it_vertically_backward question, Eli Zaretskii, 2021/12/15
- Re: move_it_vertically_backward question, Eli Zaretskii, 2021/12/15
- Re: move_it_vertically_backward question, Po Lu, 2021/12/15