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 14:52:10 +0200 Message-ID: <83lf0nl56t.fsf@gnu.org> References: <87lf0pw78r.fsf.ref@yahoo.com> <87lf0pw78r.fsf@yahoo.com> <837dc8mue3.fsf@gnu.org> <874k7cuhv4.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15096"; 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 13:57:59 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 1mx7NW-0003io-4r for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Dec 2021 13:57:58 +0100 Original-Received: from localhost ([::1]:40984 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mx7NS-0003GJ-W7 for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Dec 2021 07:57:56 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mx7Hx-0003m9-Gt for emacs-devel@gnu.org; Tue, 14 Dec 2021 07:52:13 -0500 Original-Received: from [2001:470:142:3::e] (port=36842 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 1mx7Hw-000669-V1; Tue, 14 Dec 2021 07:52:13 -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=2XbufJuW0JoeyvSjXD2HFwL1FjtmS9gd+NirUs4EQnU=; b=In+R3E2Vzs+G edBpdMV0cJhYjo6Yb5X8/blpncw6YtbQZtAv0yZGl0/Q/fWG8MamLfw/6XhLbgVl9GaT2qnueKA5e K2oyzL6Oa2Wtx8lzFdTfgaDK7YL56xYDQdWneQvtjp3ul7E5G766xQy2u+WI9Cffh9TMwmD/eh07q RuJpQQh1LAheNQSb10HKv7p5jVws844tI/Pzkbqx0pmqdiTrm/xxAQ0QBdwXsCBWZ5NxfCDt5AHOj 6Fr71Y0tsN1LfGyvXQNElMqaAvG8F8tHShoWUNWNb3Q+22JFn16shicXrpTe1vluEwd2fORetRnb7 u/cucuiNTFunSCibFImpCA==; Original-Received: from [87.69.77.57] (port=3291 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 1mx7Hw-0007hC-KZ; Tue, 14 Dec 2021 07:52:12 -0500 In-Reply-To: <874k7cuhv4.fsf@yahoo.com> (message from Po Lu on Tue, 14 Dec 2021 08:53:35 +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:281891 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Tue, 14 Dec 2021 08:53:35 +0800 > > Yes, I understand that much. This primitive is supposed to solve a > performance problem though: right now, we go through quite a few hoops > to find such a position and return its height, and I've been getting > complaints that the speed of that is unacceptable. Extending an existing primitive will give you the same performance as a new primitive. But it will also save you from reinventing the wheel and from having to deal with all the subtleties of primitives that simulate display to find some place or measure of the text as it will be on display. > Since there seems to be no faster way to do what I'm trying to, > introducing a new primitive seems to be the way to go. I'm saying that extending an existing primitive to cover your use case might be a better way forward. > > Instead, we should understand better why window-text-pixel-size > > doesn't fit your bill, and then extend it so that it does what you > > want in your use cases. > > While the performance of `window-text-pixel-size' itself is ample, > finding the target window start is not: we have to find the beginning of > the visual line, then (vertical-motion -1) in a loop calculating the > height with `window-text-pixel-size' until it reaches an appropriate > value. 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". > Hmm. Is it legal to pass a negative Y argument to `move_it_to'? "Legal", as in "no against the law"? Yes. "Valid"? no. The move_to_* functions can generally only move forward, because they use the normal "iteration through buffer text" infrastructure, and that examines characters in the order of increasing buffer positions. We don't have algorithms that can perform layout calculations while going back in the buffer. 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.