From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#56393: Actually fix the long lines display bug Date: Mon, 18 Jul 2022 12:58:59 +0000 Message-ID: References: <38c1a31040d2d2bc47ae@heytings.org> <38c1a310405bd4bbe370@heytings.org> <87a69n98yy.fsf@yahoo.com> <38c1a31040f5546dbd3a@heytings.org> <87czej6buq.fsf@gnus.org> <38c1a31040e66d2b273e@heytings.org> <834jzt59jt.fsf@gnu.org> <831qux5806.fsf@gnu.org> <9C70BEF7-08EC-46A0-89D3-547417FA01F8@gmail.com> <83let43xg9.fsf@gnu.org> <83sfna3gzq.fsf@gnu.org> <83fsja36an.fsf@gnu.org> <34362AA6-6404-4727-9C60-6B6CA6736DD4@gnus.org> <83v8rvpxx7.fsf@gnu.org> <209e6aa436f84e1f729a@heytings.org> <83sfmzpw4e.fsf@gnu.org> <83h73epq7v.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35813"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , larsi@gnus.org, 56393@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 18 15:02:30 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 1oDQOL-00096b-No for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Jul 2022 15:02:30 +0200 Original-Received: from localhost ([::1]:33122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oDQOK-0006NR-4k for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Jul 2022 09:02:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34676) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDQLy-0005Ps-T4 for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 09:00:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51741) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oDQLy-0000qs-Ar for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 09:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oDQLx-0004OP-UJ for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 09:00:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Jul 2022 13:00:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56393 X-GNU-PR-Package: emacs Original-Received: via spool by 56393-submit@debbugs.gnu.org id=B56393.165814914416774 (code B ref 56393); Mon, 18 Jul 2022 13:00:01 +0000 Original-Received: (at 56393) by debbugs.gnu.org; 18 Jul 2022 12:59:04 +0000 Original-Received: from localhost ([127.0.0.1]:49497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDQL2-0004MU-0L for submit@debbugs.gnu.org; Mon, 18 Jul 2022 08:59:04 -0400 Original-Received: from heytings.org ([95.142.160.155]:42454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDQKz-0004M3-24 for 56393@debbugs.gnu.org; Mon, 18 Jul 2022 08:59:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1658149139; bh=Lg9/J4lh/sOV+TYAAnWco+bq6KBoLPmnUWmfcw1bA+E=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=HDajTYGbSS22Up6mMAXMlTOXYpzdwv1OLVe151pCqcCupCA5kpI6N6ohA416mAYOp IYx4qFU+Q4DmZ7WBmOdoO/HlKGnW2/JxrcnNZM2F7A9iJ02nCcDgMFXoSU2gs6jycy s69GVpovONq28QbntSH885N8V+8rqqMg9Jf0h2JFfO9lqVNc5ovgc27XHAWWQKv/Ji HLefjvKDg6ZAf8KLtG6NbpUaoIyC5jkR4+H5x/PVLBzedPQkgnlsEzDNWhhPfPB55E +rATx0hHpW0eEZoJQPja6Fo7/D6y3hTbA+IV25nFlY3WuHYJJdcv2PN3vRFUjopTRx jDXUHevSBkxCQ== In-Reply-To: <83h73epq7v.fsf@gnu.org> 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:237349 Archived-At: > > Thanks. The crash is gone, of course, > That's good news. > > I can send you a backtrace from yesterday: > > [...] > > As you see, the cause of problem was the same one: > > [...] > > Since you have now moved the iteration to begin at the "narrowed" BEGV, > this crash is also gone. > That's good news, too. Thanks for the other backtrace. > > To tell the truth, I'm not sure this kind of fix is the correct > solution, because basically its success is a matter of luck (or lack > thereof). For example, recall the higher-level context of the first > segfault: > > [...] > > This is isearch.el trying to establish whether the position of the match > is visible in the window. To do that, it starts from the current > window-start position (which happens to be 1), and simulates display of > the buffer text portion up until point or until the end of window, > whichever comes first, to determine whether point is beyond the end of > the window. Your change makes the search start from some much later > position instead, which could very well produce incorrect results: > pos-visible-in-window-p could decide that point _is_ visible, when it > really isn't. (It doesn't happen in this particular case because the > newline is far away -- at the very end of the buffer -- so it isn't > visible in both cases. But that's sheer luck.) > Well, this happens only in buffers with long lines, and only when we are inside a long line, so from my point of view it works as expected, and moreover the risk is small. Would the following be better from your point of view? diff --git a/src/xdisp.c b/src/xdisp.c index d69d7440bc..572ad2b854 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -8668,18 +8668,11 @@ get_visually_first_element (struct it *it) bool string_p = STRINGP (it->string) || it->s; ptrdiff_t eob = (string_p ? it->bidi_it.string.schars : ZV); ptrdiff_t bob; + ptrdiff_t obegv = BEGV; - SET_WITH_NARROWED_BEGV (it, bob, string_p ? 0 : BEGV); - - /* Reseat again when, as a consequence of the SET_WITH_NARROWED_BEGV - above, the iterator is before bob. */ - if (!string_p && IT_CHARPOS (*it) < bob) - { - struct text_pos pos; - pos.charpos = bob; - pos.bytepos = CHAR_TO_BYTE (bob); - reseat (it, pos, true); - } + SET_WITH_NARROWED_BEGV (it, bob, + string_p ? 0 : + IT_BYTEPOS (*it) < BEGV ? obegv : BEGV); if (STRINGP (it->string)) { > > More generally, if you look at redisplay_window, you will see that about > 2/3 of its code tries very hard to reuse the previous window-start > position, before it gives up and looks for a new starting position. So > in any situation where the previous window-start is far enough before > point, all that code will basically work with a buffer position that is > at risk of being before the "narrowed" BEGV. Thus, any code there which > tries stuff like start_display+move_it_to will risk hitting this kind of > problems -- either FETCH_BYTE will crash, or we risk producing the wrong > result because we force the code to jump to the "narrowed" BEGV before > doing anything, while its caller expects results relative to a different > position. > I understand. But note that temporarily narrowing the buffer happens only at a few well-chosen places, which are situated rather low in the abstraction layers, so the effect on other parts of the code is nil. > > I think this is because the display engine assumes that BEGV stays put > during the entire redisplay_window lifetime, i.e. that all of the > subroutines it calls see the same value of BEGV. This is no longer so > on the branch, and I wonder whether and how we should handle this new > situation to keep the display code stable and reliable. > I don't know.