From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#50096: args-out-of-range in redisplay_internal Date: Wed, 18 Aug 2021 19:32:01 +0300 Organization: LINKOV.NET Message-ID: <87y28yspf2.fsf@mail.linkov.net> References: <87r1esys1a.fsf@mail.linkov.net> <83v94456sn.fsf@gnu.org> <87h7foyo67.fsf@mail.linkov.net> <87im04x8mm.fsf@mail.linkov.net> <83sfz8543o.fsf@gnu.org> <874kbox736.fsf@mail.linkov.net> <83mtpf6hjb.fsf@gnu.org> <87eearx5tz.fsf@mail.linkov.net> <83k0kj6gmq.fsf@gnu.org> <87im03tc6g.fsf@mail.linkov.net> <834kbn54kq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21891"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: 50096@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 18 18:50:00 2021 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 1mGOlL-0005Wy-Hj for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 18 Aug 2021 18:49:59 +0200 Original-Received: from localhost ([::1]:34614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mGOlK-0007T8-Du for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 18 Aug 2021 12:49:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGOhW-0007mo-BA for bug-gnu-emacs@gnu.org; Wed, 18 Aug 2021 12:46:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45904) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mGOhW-0005CJ-4R for bug-gnu-emacs@gnu.org; Wed, 18 Aug 2021 12:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mGOhW-0002AI-27 for bug-gnu-emacs@gnu.org; Wed, 18 Aug 2021 12:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Aug 2021 16:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50096 X-GNU-PR-Package: emacs Original-Received: via spool by 50096-submit@debbugs.gnu.org id=B50096.16293051038193 (code B ref 50096); Wed, 18 Aug 2021 16:46:02 +0000 Original-Received: (at 50096) by debbugs.gnu.org; 18 Aug 2021 16:45:03 +0000 Original-Received: from localhost ([127.0.0.1]:57439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGOgZ-000284-38 for submit@debbugs.gnu.org; Wed, 18 Aug 2021 12:45:03 -0400 Original-Received: from relay8-d.mail.gandi.net ([217.70.183.201]:59391) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGOgU-00026S-01 for 50096@debbugs.gnu.org; Wed, 18 Aug 2021 12:44:58 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 054CB1BF207; Wed, 18 Aug 2021 16:44:50 +0000 (UTC) In-Reply-To: <834kbn54kq.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 18 Aug 2021 15:18:29 +0300") 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:212163 Archived-At: >> I don't understand how this is supposed to work. The buffer " *Minibuf-0*" >> is always empty at the time of calling message3_nolog, whereas the buffer >> " *Echo Area 0*" contains the message to display. > > Yes, some code switches to another buffer at the wrong moment. There are no buffer switching involved neither in the successful case nor in the failing case. >> 5. redisplay_internal calls hscroll_window_tree >> where cursor_row already contains information >> that was valid when " *Echo Area 0*" was temporarily >> displayed in mini_window: > > Any idea why we call hscroll_window_tree in this case? Here are all differences in cursor_row between success and failure: @@ -1,8 +1,8 @@ (gdb) p *cursor_row { x = 0, y = 228, - pixel_width = 1610, + pixel_width = 1910, ascent = 15, height = 19, phys_ascent = 12, @@ -26,8 +26,8 @@ }, end = { pos = { - charpos = 1897, - bytepos = 1897 + charpos = 2150, + bytepos = 2150 }, overlay_string_index = -1, string_pos = { @@ -41,14 +41,14 @@ bytepos = 1737 }, maxpos = { - charpos = 1897, - bytepos = 1897 + charpos = 2150, + bytepos = 2150 }, overlay_arrow_bitmap = 0, left_user_fringe_bitmap = 0, right_user_fringe_bitmap = 0, left_fringe_bitmap = 0, - right_fringe_bitmap = 0, + right_fringe_bitmap = 31, left_user_fringe_face_id = 0, right_user_fringe_face_id = 0, left_fringe_face_id = 0, @@ -59,7 +59,7 @@ redraw_fringe_bitmaps_p = true, enabled_p = true, truncated_on_left_p = false, - truncated_on_right_p = false, + truncated_on_right_p = true, continued_p = false, displays_text_p = true, ends_at_zv_p = true, When it fails, truncated_on_right_p is true, that causes executing code block with init_to_row_start in hscroll_window_tree, that fails with truncated long miniwindow lines. In the successful case truncated_on_right_p=false allows hscroll_window_tree to skip the block with init_to_row_start, and other hscrolling. > I'm guessing this is due to some customizations of yours, in which > case I'd appreciate a reproduction recipe starting from "emacs -Q". > It is very hard to debug such problems via email. It's 100% reproducible for me, but I'm not sure how easy would be to create a test case for "emacs -Q". >> > You are saying that if you remove the ":(literal)" part without >> > changing anything else, the problem goes away? >> >> Indeed, it broke after the commit 3572613550. >> But after applying this patch it works again without errors: > > Does this patch work by preventing hscrolling? > >> I guess additional ":(literal)" string increases the length >> of the displayed message, and longer message triggers the bug. > > How does it trigger it? via hscrolling or some other way? It reduces the length of the displayed message, so there is no wrapped line and no hscrolling.