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.bugs Subject: bug#57669: 29.0.50; C-n, C-p off under long lines Date: Sat, 10 Sep 2022 10:45:42 +0300 Message-ID: <838rmrbrkp.fsf@gnu.org> References: <87y1uujufi.fsf@dick> <83k06effg6.fsf@gnu.org> <87tu5ijcqg.fsf@dick> <2e25ca87e3d9ee13ba3e@heytings.org> <87illxka46.fsf@dick> <8335d1dr39.fsf@gnu.org> <87mtb8hezl.fsf@dick> <838rmsd4cc.fsf@gnu.org> <878rmsh9me.fsf@dick> <87zgf8fsv3.fsf@dick> <83zgf8bkmn.fsf@gnu.org> <83v8pwbjvy.fsf@gnu.org> <87a678fnnz.fsf@dick> <83r10kbex8.fsf@gnu.org> <875yhwflw7.fsf@dick> <83pmg4bcjt.fsf@gnu.org> <87wnace31g.fsf@dick> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9483"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57669@debbugs.gnu.org To: dick Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 10 09:47:31 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oWvD7-0002KN-DN for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Sep 2022 09:47:29 +0200 Original-Received: from localhost ([::1]:41336 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWvD5-00044k-Ga for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Sep 2022 03:47:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51860) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWvCg-00043P-Qk for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2022 03:47:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47817) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oWvCg-0007kh-IP for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2022 03:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oWvCg-0002yW-EU for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2022 03:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Sep 2022 07:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57669 X-GNU-PR-Package: emacs Original-Received: via spool by 57669-submit@debbugs.gnu.org id=B57669.166279597111348 (code B ref 57669); Sat, 10 Sep 2022 07:47:02 +0000 Original-Received: (at 57669) by debbugs.gnu.org; 10 Sep 2022 07:46:11 +0000 Original-Received: from localhost ([127.0.0.1]:36511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWvBq-0002wy-Ge for submit@debbugs.gnu.org; Sat, 10 Sep 2022 03:46:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWvBo-0002wl-Ll for 57669@debbugs.gnu.org; Sat, 10 Sep 2022 03:46:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38480) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWvBj-0007g8-Ex; Sat, 10 Sep 2022 03:46:03 -0400 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=I5T0vok+2T+S0rqWJy5IsE7OeWexVV46Dq1u1u+SmLQ=; b=dX8U5XfO8y4o CCgeA44oCXS8RN2j+AuzNC/JL7w48Isp+uzPzYeNbj2pVqxIwlI5/fhBkVCrPjH7+LXITI8gnx3M9 5+2JOPyiBW2g1zHapXP/h6z5aFpJd7lh2kz4zE6mkf73RmDHm6qjKGUeghCYo9aHZJ0vY1qgcPDet EVrqFzKapYq2lBNcJghhVx0V9SRIJy+dLfQm79Kv9V5AYmDZIJAV0tLBiaR0H2rCIe1zYyPUy/0EW BeqWNWnYs6ajQmzMp9M22hYirYA1qRPDwCDGaoEGVMPY2Mp4m6CC6Oxfaq8XwufqDF0ni0R8VkK5K lRLY5+3bhY0Aaz6+2D9tXw==; Original-Received: from [87.69.77.57] (port=4047 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 1oWvBi-00031T-U9; Sat, 10 Sep 2022 03:46:03 -0400 In-Reply-To: <87wnace31g.fsf@dick> (message from dick on Fri, 09 Sep 2022 15:55:07 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:242086 Archived-At: > From: dick > Cc: 57669@debbugs.gnu.org > Date: Fri, 09 Sep 2022 15:55:07 -0400 > > > showing your code that deals with very long lines and explaining how > > it solves that > > I can't believe I'm dignifying this. All line references from commit > beb489e. > > xdisp.c[9319,9369]: Calculates dy algebraically without char-by-char. This uses state variables from 'struct it' which are _local_ and _momentary_, i.e. they can change as result of processing any buffer position, and reflect only the latest change, forgetting what was before. Specifically, it->method is such a state variable. So making global conclusions, such as that "all characters will have the same metrics on display", based on it->method is fundamentally wrong, and can only be true in very simple situations. The buffer->text->monospace flag is likewise implemented based on simplistic assumptions: that only text properties could violate the "monospace-ness" attribute. Here's why this is simplistic: . faces can be applied by overlays as well . faces can be applied directly by C code . faces can be applied by using glyphs from display-tables . even if we only have the default face, fonts used for various non-ASCII characters can have different metrics from the default face's font, and in some cases they can even be variable-pitch fonts . portions of display can be made invisible by selective-display, not just by 'invisible' properties (I'm not claiming that the above is the exhaustive list of all the reasons that the assumptions in behaved_p could be violated; there could be more of them.) > xdisp.c[9537,9577]: Calculates CAPPED to limit char-by-char scan for > moving backwards (Blandy and Moellmann wrote xdisp like a singly linked > list -- fast and precise forwards, much less so going backwards). I cannot see how the above description is related to the actual code in that part of xdisp.c: there's no char-by-char movement back in the corresponding parts of our code; instead, we move back by lines, then move forward by characters -- and that's what the code there does as well. So I think this part of the code is equivalent to what we do, in back_to_previous_visible_line_start, and should have the same performance. But maybe I'm missing something -- was this change profiled, and if so, what were the results? And if this code is significantly faster, which of its changes is responsible for the speedups? And in which kind of files under what major modes were these speedups measured? In any case, the replacement code uses behaved_p, whose problematic assumptions I already explained above. To comment on the above description: in general, moving the iterator backwards needs to consider all the changes in the state variables of 'struct it' that eventually affect the metrics and the layout calculations. It is _not_ the same as moving back by characters, and the reason is that the state changes of 'struct it' are defined (in set_iterator_to_next, get_next_display_element, and their subroutines) only for moving forward, not for moving back. That is why all move_it_* functions cannot move back, except by going to a preceding newline and then coming forward.