From: Eli Zaretskii <eliz@gnu.org>
To: Po Lu <luangruo@yahoo.com>
Cc: emacs-devel@gnu.org
Subject: Re: move_it_vertically_backward question
Date: Tue, 14 Dec 2021 15:45:53 +0200 [thread overview]
Message-ID: <837dc7l2pa.fsf@gnu.org> (raw)
In-Reply-To: <875yrrtiwj.fsf@yahoo.com> (message from Po Lu on Tue, 14 Dec 2021 21:28:44 +0800)
> 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.
next prev parent reply other threads:[~2021-12-14 13:45 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87lf0pw78r.fsf.ref@yahoo.com>
2021-12-13 2:47 ` move_it_vertically_backward question Po Lu
2021-12-13 14:50 ` Eli Zaretskii
2021-12-14 0:53 ` Po Lu
2021-12-14 12:52 ` Eli Zaretskii
2021-12-14 13:28 ` Po Lu
2021-12-14 13:45 ` Eli Zaretskii [this message]
2021-12-15 1:18 ` Po Lu
2021-12-15 3:27 ` Eli Zaretskii
2021-12-15 3:30 ` Po Lu
2021-12-15 13:27 ` Eli Zaretskii
2021-12-15 13:39 ` Po Lu
2021-12-15 2:13 ` Po Lu
2021-12-15 10:28 ` Po Lu
2021-12-15 13:56 ` Eli Zaretskii
2021-12-15 13:25 ` Eli Zaretskii
2021-12-15 13:38 ` Po Lu
2021-12-15 14:50 ` Eli Zaretskii
2021-12-16 0:41 ` Po Lu
2021-12-16 8:29 ` Eli Zaretskii
2021-12-16 9:25 ` Po Lu
2021-12-16 10:04 ` Eli Zaretskii
2021-12-16 10:27 ` Po Lu
2021-12-16 12:17 ` Po Lu
2021-12-16 13:27 ` Eli Zaretskii
2021-12-16 13:34 ` Po Lu
2021-12-16 13:59 ` Eli Zaretskii
2021-12-17 1:45 ` Po Lu
2021-12-18 10:28 ` Eli Zaretskii
2021-12-18 10:49 ` Po Lu
2021-12-18 11:03 ` Eli Zaretskii
2021-12-18 11:18 ` Po Lu
2021-12-18 11:29 ` Eli Zaretskii
2021-12-18 11:31 ` Po Lu
2021-12-18 11:35 ` Eli Zaretskii
2021-12-18 11:39 ` Po Lu
2021-12-19 0:54 ` Po Lu
2021-12-19 8:29 ` Eli Zaretskii
2021-12-19 9:16 ` Po Lu
2021-12-19 9:27 ` Eli Zaretskii
2021-12-19 10:25 ` Po Lu
2021-12-19 18:07 ` Eli Zaretskii
2021-12-20 1:05 ` Po Lu
2021-12-21 12:58 ` Po Lu
2021-12-21 17:07 ` Eli Zaretskii
2021-12-22 0:49 ` Po Lu
2021-12-22 14:59 ` Eli Zaretskii
2021-12-23 1:30 ` Po Lu
2021-12-23 9:49 ` Eli Zaretskii
2021-12-23 10:29 ` Po Lu
2021-12-23 10:39 ` Eli Zaretskii
2021-12-23 10:42 ` Po Lu
2021-12-23 10:50 ` Eli Zaretskii
2021-12-23 10:55 ` Po Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837dc7l2pa.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=luangruo@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).