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#62637: 29.0.60; Issues when displaying images Date: Mon, 03 Apr 2023 16:35:02 +0300 Message-ID: <83355hw0l5.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29358"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62637@debbugs.gnu.org To: Abdul-Lateef Haji-Ali , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 03 15:35:37 2023 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 1pjKLR-0007SO-Gi for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 Apr 2023 15:35:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pjKKv-0007xt-TI; Mon, 03 Apr 2023 09:35:05 -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 1pjKKs-0007wS-Ju for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 09:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pjKKs-0002GA-BQ for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 09:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pjKKs-0000om-6c for bug-gnu-emacs@gnu.org; Mon, 03 Apr 2023 09:35: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: Mon, 03 Apr 2023 13:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62637 X-GNU-PR-Package: emacs Original-Received: via spool by 62637-submit@debbugs.gnu.org id=B62637.16805288913124 (code B ref 62637); Mon, 03 Apr 2023 13:35:02 +0000 Original-Received: (at 62637) by debbugs.gnu.org; 3 Apr 2023 13:34:51 +0000 Original-Received: from localhost ([127.0.0.1]:43735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pjKKg-0000oK-H1 for submit@debbugs.gnu.org; Mon, 03 Apr 2023 09:34:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pjKKe-0000nw-BB for 62637@debbugs.gnu.org; Mon, 03 Apr 2023 09:34:48 -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 1pjKKY-0002DL-4z; Mon, 03 Apr 2023 09:34:42 -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=X/Cmmpv9JHfTtJyAmxtGbLKCUEeWqY192p8Ndv58Y/M=; b=B73pIMcjiUAk xr3rRM95+u4ZXCEBJ9ECKPa57mfqI/33D8FwDsqZiozTJvL/t+xkQ9WgG65RAGxzmOyXYHkWySGtY 7WxnvFMEQ+Kr9+W7FwVZXGseBojFgJ4yK4MPboTAOZYtXpEaL0xdLMgPnYTNh6soCc5BDYQ0QH1lS IvjGl4DCP6/y93cF/HZCR7skPzdS5WzGqs07vXfRehrbhwvTWh5Y79FtAOrnnvwSo8QP0tFwW7lgT 390Q3h9Qo0xbVzrbTN9CJkOhRDd/8sjWw2Kn1qSN33dcaF2UflMzOyYsmAEHG+KRcd4KtdJ8/8uaj ohBGPF/1y2SEG7Cmmfd5Uw==; Original-Received: from [87.69.77.57] (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 1pjKKX-0003XG-Lj; Mon, 03 Apr 2023 09:34:41 -0400 In-Reply-To: (bug-gnu-emacs@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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259179 Archived-At: > Date: Sun, 02 Apr 2023 14:31:12 +0100 > From: Abdul-Lateef Haji-Ali via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > It seems that `mm-inline-image` switched to using `insert-image` instead of `put-image` which resulted in some regressions in notmuch that I noticed between emacs 29 and emacs 28.2. However, I tracked down the discrepancy to the following issues in displaying images in emacs-29. Maybe I'm missing something (you've lumped together several code fragments without too many explanations), but I see no discrepancies here, only unjustified expectations. > First the following code (assuming some image in /tmp/tmp.png), executed in "emacs -Q" on either emacs 28.2 or emacs 29: > > (let (content-begin > content-end) > (goto-char (point-max)) > (insert "\n") > (setq content-begin (point)) > (insert-image (create-image "/tmp/tmp.png")) > (setq content-end (point)) > > ;; I expect the following line to indent the image (or not). > ;; instead the image is removed completely > ;;(indent-rigidly content-begin content-end 1) indent-rigidly removes the existing whitespace and then inserts new whitespace as needed. And insert-image by default puts the 'display' property on a space character. Does this explain what you see? > ;; This line should hide the image, but it doesn't > ;;(overlay-put (make-overlay content-begin content-end) 'invisible t) > ) Due to the way the Emacs display engine is implemented, 'display' properties (which is how images are implemented in Emacs) are processed before invisible properties. And a 'display' property that specifies an image is a "replacing" property: the image is displayed _instead_ of the buffer text which has this property, and the buffer text itself is skipped. What this means in this case is that the overlay with the invisible property is completely ignored by the display code, because the buffer text on which you put that overlay is skipped when the 'display' property is processed. > Similar code to this example is executed in notmuch when displaying message, but using `mm-inline-image` instead of insert-image: I don't understand all the fine details of what mm-inline-image does, but its current implementation again uses a space for the text on which it puts the 'display' property that is displayed as the image. > As a last test, in case it is helpful, I tried the following in emacs 29 using `put-image` instead of `insert-image` (`mm-inline-image` uses in Emacs 28.2 uses `put-image` while in Emacs 29 it uses 'insert-image'), and noticed an equally puzzling behaviour: > > (let (content-begin > content-end) > (goto-char (point-max)) > (insert "\n") > > (setq content-begin (point)) > (put-image (create-image "/tmp/tmp.png") (point-marker)) > (setq content-end (point)) > > ;; I expect the following line to indent the image (or not). > ;; instead the image is removed completely > ;;(indent-rigidly content-begin content-end 1) > > ;; This line should hide the image, but it doesn't > ;;(overlay-put (make-overlay content-begin content-end) 'invisible t) > ) > > In this case, `indent-rigidly` does not remove the image, but hiding the overlay does not work. For the overlays part, see the above: put-image cannot change that basic fact. If you are saying that notmuch was able to hide images by using overlays, you will need to tell more and show some code which did that in some prior version of Emacs. As for indentation: put-image uses a different default for the text on which it puts the image 'display' property. That explains why re-indentation didn't remove the image in Emacs 28. Perhaps we should modify mm-inline-image to use a non-whitespace text on which to put the image? Can you try that? Lars, any reason you explicitly used whitespace as the STRING argument of insert-image that replaced put-image in mm-inline-image?