From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: move_it_vertically_backward question Date: Tue, 14 Dec 2021 15:45:53 +0200 Message-ID: <837dc7l2pa.fsf@gnu.org> References: <87lf0pw78r.fsf.ref@yahoo.com> <87lf0pw78r.fsf@yahoo.com> <837dc8mue3.fsf@gnu.org> <874k7cuhv4.fsf@yahoo.com> <83lf0nl56t.fsf@gnu.org> <875yrrtiwj.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11955"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 14 15:03:16 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mx8Oh-0002rW-B7 for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Dec 2021 15:03:15 +0100 Original-Received: from localhost ([::1]:55424 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mx8Og-0006db-3R for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Dec 2021 09:03:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56408) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mx87y-0003Wk-2p for emacs-devel@gnu.org; Tue, 14 Dec 2021 08:45:58 -0500 Original-Received: from [2001:470:142:3::e] (port=39004 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mx87x-0006KL-QH; Tue, 14 Dec 2021 08:45:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wcEgM1e6GHUUHG5/OZ6HiyIwHDz6VceWx8dryspeDTY=; b=EvhAlOJjZjtg qvsBXo2SyPY8sn29Ig8DOtN083yGNxxDAFq1NOk4c1cKZtDGjKah3r3sVQ/UHIAecYoFbYApGuZDg f+rrteFM/Ma0CA3otNlZJbjbeNh8QteUEGTfNXnq+Z11v+hNhCQ+jdl8s1/8oCCHl0Z3FxSFPfY+v c66ljF6qJlJFEt0x6p4qQaJJmd2qtEGtKHpkAZ+0t1jj/x3ONg/yniOA2UJ2iHCoSVTTvo0QjTWr6 8hQ2O7kY38gZ4ADs7SJIxliS7iqUseWy4kBjAnizqDEA2+TuLoMTtkynw042RWb4XA9eMoEQRFOiF /gZO/lV+gbnf9C1t61ZAfA==; Original-Received: from [87.69.77.57] (port=2666 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mx87w-0004LF-QX; Tue, 14 Dec 2021 08:45:57 -0500 In-Reply-To: <875yrrtiwj.fsf@yahoo.com> (message from Po Lu on Tue, 14 Dec 2021 21:28:44 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281900 Archived-At: > From: Po Lu > 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.