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: Mon, 13 Dec 2021 16:50:12 +0200 Message-ID: <837dc8mue3.fsf@gnu.org> References: <87lf0pw78r.fsf.ref@yahoo.com> <87lf0pw78r.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19139"; 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 Mon Dec 13 15:52:27 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 1mwmgk-0004gX-NZ for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Dec 2021 15:52:26 +0100 Original-Received: from localhost ([::1]:33612 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mwmgj-0006di-Kd for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Dec 2021 09:52:25 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49030) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwmeg-0003r4-IX for emacs-devel@gnu.org; Mon, 13 Dec 2021 09:50:19 -0500 Original-Received: from [2001:470:142:3::e] (port=33490 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 1mwmeg-0000ak-8y; Mon, 13 Dec 2021 09:50:18 -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=ymIOpkTR767xQtJhLPcN/rFdEcR1kKh25vn7PLJXxu0=; b=lMEPjFxpGQvN q5o1UoEH+Guk/vWBsnP4DF3mEAuzMLAxm1JJk6Iik7u6C8XdWIjPU9veDEawzeDj7jmktd4ee4NI9 DVNOLumO8qbXdfoz9B7cmPi0wbLE71gTyDxLWi1GZM0rZ8ZdmZatkXC8gyHvTK7+BY1Dlz/NOdUZM BZy+X2G4TuYdekEw5uLUVyv45cc9dpKzuuQv3oqDN4NXFTp7mERuYWLbJJgizKo+KJPVZ1urEm/3r rQJKB3WR9GiATcU+P3bl2RmLOT2OkpbpK9zCPlgmgbYH6tfPfWGNeGNtx0fb5EYty1uguYfQXexYv yMIwJ2sVpkLewerQqAfudw==; Original-Received: from [87.69.77.57] (port=1570 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 1mwmef-0004zF-O6; Mon, 13 Dec 2021 09:50:18 -0500 In-Reply-To: <87lf0pw78r.fsf@yahoo.com> (message from Po Lu on Mon, 13 Dec 2021 10:47:48 +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:281851 Archived-At: > From: Po Lu > Date: Mon, 13 Dec 2021 10:47:48 +0800 > > I've been trying to introduce a new redisplay primitive to speed up > precision pixel scrolling I'm not sure this is the way to go, judging by what you told on help-gnu-emacs. The main reason is that window-text-pixel-size, which you said doesn't do what you want, uses exactly the same technique as you are trying to do in this new primitive, and so whatever problems you have with window-text-pixel-size, you will bump into them (or similar problems) with your new primitive as well. This stuff is always extremely tricky when advanced display features are used, like display and overlay strings with embedded newlines, line-prefix, line numbers, etc. There's no easy way around this complexity. 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. That said, to answer your question: > If there are 3 lines above window start, all of which are 17 pixels > tall, calling this new primitive with PIXELS anything between 18 and 33 > will result in the start and height of the first line being returned, > while I would have expected it to move onto the second line, as anything > between 18 and 33 pixels above window start should be inside the second > line. The commentary to the function doesn't tell the whole story. In fact, it always undershoots first, because of this: /* Estimate how many newlines we must move back. */ nlines = max (1, dy / default_line_pixel_height (it->w)); This is integer division, so it truncates the number of lines. E.g., in your case, with DY between 17 and 33 you get 1 line, not more. Then it moves back by that number of physical lines, which is why you get the line before window-start. And then it can move farther back, but only if the undershoot is "large enough": /* If we did not reach target_y, try to move further backward if we can. If we moved too far backward, try to move forward. */ if (target_y < it->current_y /* This is heuristic. In a window that's 3 lines high, with a line height of 13 pixels each, recentering with point on the bottom line will try to move -39/2 = 19 pixels backward. Try to avoid moving into the first line. */ && (it->current_y - target_y > min (window_box_height (it->w), line_height * 2 / 3)) && IT_CHARPOS (*it) > BEGV) { move_trace (" not far enough -> move_vert %d\n", target_y - it->current_y); dy = it->current_y - target_y; goto move_further_back; } That "2/3rd of line height" threshold heuristic is the reason why it not always moves one more line back. On my system, the default pixel height of a line is 16, so it moves to the second line before window-start for DY >= 27, since 2/3rd of 16 is 10.