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#73600: 31.0.50; Visual wrap prefix mode and image display Date: Thu, 03 Oct 2024 13:59:35 +0300 Message-ID: <86h69tzc2w.fsf@gnu.org> References: <87wmiq1wsd.fsf@gautierponsinet.xyz> <86cyki1pgu.fsf@gnu.org> <86bk021p1k.fsf@gnu.org> <3117d4b7-751c-8c6d-8acf-48dc6464e723@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11074"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73600@debbugs.gnu.org, gautier@gautierponsinet.xyz To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 03 13:02:25 2024 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 1swJbD-0002kD-EV for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 03 Oct 2024 13:02:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1swJat-0005IF-C9; Thu, 03 Oct 2024 07:02:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1swJar-0005Hs-FE for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2024 07:02:01 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1swJar-0003yd-6K for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2024 07:02:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=meEU8jS4svC0p7uBcTWGJ4mYHJ45LdgWzyRuU3Vw5PQ=; b=mVsuyq57HsTOf/ZUqKtFOurzvMnlmiI0PIhOB2c6SzqJh/xcgpgHUdruIR1evGdQ46biIOFJ+JWEm/T+mssUMUTghgykU9DOEmCATbA/DqwI3VVhjA42tAljBbWthiHUssZaGDJ/gMIfchsR02LA0kfSX0Ym7nGIAPTBEaMmWbj9ZLuuArvS52uRivg5NBE8nw3+VcyyDovsBUY/OCIAoe5ZrKE16MP6Iya8DebS/ZujoUIe4DERROia4PvAPE2uvycZ9yYUSTg29W1t5w2/sqCZVYiE7gdKzi4RJf4zue86VKIY3AmOvIJsutgvdaiUY8lw/BIWDiK+3uibGB4wyA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1swJas-0004W9-In for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2024 07:02: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: Thu, 03 Oct 2024 11:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73600 X-GNU-PR-Package: emacs Original-Received: via spool by 73600-submit@debbugs.gnu.org id=B73600.172795331717350 (code B ref 73600); Thu, 03 Oct 2024 11:02:02 +0000 Original-Received: (at 73600) by debbugs.gnu.org; 3 Oct 2024 11:01:57 +0000 Original-Received: from localhost ([127.0.0.1]:60117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swJan-0004Vm-Ah for submit@debbugs.gnu.org; Thu, 03 Oct 2024 07:01:57 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swJak-0004VY-Ny for 73600@debbugs.gnu.org; Thu, 03 Oct 2024 07:01:55 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1swJYX-0003Mr-PZ; Thu, 03 Oct 2024 06:59:37 -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=meEU8jS4svC0p7uBcTWGJ4mYHJ45LdgWzyRuU3Vw5PQ=; b=ocBs/jfzpQ3h TchLPtvh385JZFh6ryH1PXmkS4LnNpeDrDlGNnMPJkY8iTzj0GDDh0hGRuC4KIjdOVFsLxkkL+m/Y cLO1JUrirDM4LQ9ZU/gTBX7REQQSXyFqVNFiplIbYEOgxSsGs6NSiThCHrnV/yXiwbkJPXctmOFZr vpVQvSzRhKCa7MHOqFvuBmmid41iUANASqNv3DOKH7Xdph9Jkwj8ttcOZqy2eOZ7+claTw0R1d7Aa 8fKohBjCEd4XPMMPGhICxGO25D/n4FfjpSjrMT0GHr/1/v1eaAZQoF4TbB3PTRn+/tfwmmfwDf4XN gkDI41GqACh8Zh+jZAXeWw==; In-Reply-To: <3117d4b7-751c-8c6d-8acf-48dc6464e723@gmail.com> (message from Jim Porter on Wed, 2 Oct 2024 09:37:48 -0700) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292896 Archived-At: > Date: Wed, 2 Oct 2024 09:37:48 -0700 > Cc: 73600@debbugs.gnu.org > From: Jim Porter > > On 10/2/2024 8:51 AM, Eli Zaretskii wrote: > >> Cc: 73600@debbugs.gnu.org > >> Date: Wed, 02 Oct 2024 18:42:09 +0300 > >> From: Eli Zaretskii > >> > >>> In emacs -Q: > >>> - enable global-visual-wrap-prefix-mode, > >>> - open the attached image. > >> > >> In a build with --enable-checking, this recipe causes an assertion > >> violation: > > > > And in Emacs 30 the problem doesn't happen, so this is some regression > > in Emacs 31. Probably due to my changes in commit 71505b723c9f. > > > > Jim, any ideas or suggestions? > > Strangely, this doesn't seem to happen with every image. "splash.png" in > the Emacs repository seems fine, for example. I also can't reproduce > this in EWW, even by opening the bad image reported in this bug. It depends on the width of the image and the contents of the image file. As soon as you show an image whose width is as wide or wider than the window, and/or the image file has newline bytes, the problem happens. Note that displaying splash.svg, the problem happens even through the image is not wider than window. See below why this happens. I've installed a fix which avoids the assertion violations in a build with --enable-checking. The fix does not prevent displaying multiple images where only one should be shown -- because that is AFAICT a bug in visual-wrap-prefix-mode, and should be fixed there. What happens is that displaying an image in a buffer places a single 'display' property on the entire buffer portion which should be displayed as an image, and the value of the property is the image spec. When visiting an image file, that property spans the entire contents of the image file. In this situation, the analysis of the buffer text performed by visual-wrap-prefix-mode, which looks at newlines and tries to calculate the suitable prefix width, is completely wrong, because the buffer text (which are just the raw bytes of the image file) is replaced on display by the image, and the calculations based on character width are all wrong. But visual-wrap-prefix-mode does still make these calculations, and as result could decide that a min-width or align-to display property should be placed on some of these raw bytes. Since visual-wrap-prefix-mode uses add-display-text-property, which attempts to keep existing display properties when it adds additional ones, the result is that the single display property that specified the image is broken into several identical display properties (some with min-width added, some without). And since these properties are not 'eq' to one another, Emacs shows N identical images instead of just one. The solution, I think, is for visual-wrap-prefix-mode to ignore text that is covered by replacing display properties, at least those which specify images, xwidgets, fringes, etc. It's possible that we want to pay attention to display properties whose value is a string, but not to any others. > One option might simply be to disable 'visual-wrap-prefix-mode' when in > 'image-mode'. I don't think wrapping is useful in that context. I think image-mode is just the tip of a very large iceberg, see above: visual-wrap-prefix-mode currently doesn't correctly handle text covered by display properties. I think this bug was uncovered when we removed on master a few artificial restrictions on min-width, such as non-support for display and overlay strings.