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#16992: feature request: background images Date: Fri, 08 Nov 2024 17:46:10 +0200 Message-ID: <86r07lohj1.fsf@gnu.org> References: <531F9A02.5060504@beloved.name> <9a735b38-6f08-4450-8522-44442bdcc02c@imayhem.com> <86wmhfr35a.fsf@gnu.org> <17673493-4117-47a8-a18b-e49a236f1d00@imayhem.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13585"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 16992@debbugs.gnu.org To: Cecilio Pardo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 08 16:47:51 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 1t9RDC-0003Jq-P6 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 08 Nov 2024 16:47:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t9RCW-0002W0-G7; Fri, 08 Nov 2024 10:47:11 -0500 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 1t9RCR-0002Ez-BJ for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2024 10:47:03 -0500 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 1t9RCR-0006Gl-2i for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2024 10:47:03 -0500 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=u96CDBbxBbSTxiAtQ30kg+HWYW3uxajtH2bFmqK/AR4=; b=mrIGP0x78tTG5Kj1JPj3VqyTDinrKRlzigY1k7VZdZaq3V6JTJ7TsBcWC6FqEXfySOgFKw0w7QtFHC/6a42ps5jmjwD4ki6+rWfIXyYkRWwDS01tz7GEh+q9C5CesJxX77wefEkrJjYTyBmK9vZ9VZznbW4o497o9nILu4jSuZs63XSQ8jmzQSAKqvXQqfLI6MhYou93NXadcxHzQ47gsFJlYYPWBYCzmP4BB1kQEu3VySS2gFZzbYzLy3HGnOMu/diCO4wp9V35DzWT4oDeMo+EkDVDUIfOV7OT8LUU6qBcYXz4FawA8JXRcB4LKC3EsMsccjb5iEbw0AQIaUOmgA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t9RCQ-0004hf-LE for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2024 10:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Nov 2024 15:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16992 X-GNU-PR-Package: emacs Original-Received: via spool by 16992-submit@debbugs.gnu.org id=B16992.173108081918068 (code B ref 16992); Fri, 08 Nov 2024 15:47:02 +0000 Original-Received: (at 16992) by debbugs.gnu.org; 8 Nov 2024 15:46:59 +0000 Original-Received: from localhost ([127.0.0.1]:51765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9RCM-0004hM-VY for submit@debbugs.gnu.org; Fri, 08 Nov 2024 10:46:59 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9RCI-0004h6-2c for 16992@debbugs.gnu.org; Fri, 08 Nov 2024 10:46:58 -0500 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 1t9RC8-0006Dv-18; Fri, 08 Nov 2024 10:46:45 -0500 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=u96CDBbxBbSTxiAtQ30kg+HWYW3uxajtH2bFmqK/AR4=; b=pa1b2sajs38l vocZDPd0h3hY6PX16p5e2CowDiWvUY6VEDWDHkN4JwAQCT+aBrlyhH7c6kRFI29Ozr4qn2Gu3YPXP B7w7OiuiFYZlGRgBcuQZlPOsB6f8iY3Zf+1DHG9Ur9+ggeFrvZpdS9QmGIdGzb9Ek41pMDezMT7iR HPN7D+5+nGBA5gj5HKJIwjEEHgvfX6nV/7Mp8Ioh2staUXfeBV7bATphRiWu6QxGQD59x7qb4W5/I zbxri7DZqJt+pqLD6gDiqy9lhsAJy+P+jmT3/v2jPE/CK3CCrB+wy0IT01gjBJawth52NBgKPrSqi zOsdpszc2R/BSQJXZ/e5iQ==; In-Reply-To: <17673493-4117-47a8-a18b-e49a236f1d00@imayhem.com> (message from Cecilio Pardo on Fri, 8 Nov 2024 14:59:20 +0100) 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:295075 Archived-At: > Date: Fri, 8 Nov 2024 14:59:20 +0100 > Cc: 16992@debbugs.gnu.org > From: Cecilio Pardo > > Here is the incomplete patch that implements background images. Thanks. I'm not yet sure I understand the overall picture and its implications, hence the questions below. > It works by adding a call to complex_bkg_clear_frame_area on all > functions that clear the background. These are the functions for w32 > port. For the cairo port, they are parallel: > > w32_clear_frame_area, w32_clear_glyph_string_rect, > w32_draw_stretch_glyph_string, w32font_draw > > I know I'm missing at least w32_draw_image_glyph_string, but works well > enough for a test. > > To setup the backgroud image for a frame, you would do something like > this: > > (progn > (setq bkg (create-image "icons/hicolor/128x128/apps/emacs.png")) > (frame-set-background-image (selected-frame) bkg 'center nil) > (frame-set-background-policy (selected-frame) t)) So showing a vertical line for the fill-column indication would need to define a background image for a frame? How do we control the horizontal coordinate where the line is drawn? > The image can be placed in the center, or on sides or corners with 'n, > 's, 'se, 'sw, etc. The background can be filled be repeating the image > passing t as the last parameter of frame-set-background-image. Why not let Lisp specify explicit coordinates for the image? > Apart from the obvious overhead of drawing the image pixels, > unfortunately the frame contents can't be scrolled to reuse text pixels > (dispnew.c:scrolling_window). I don't think this can't be fixed without > big changes. Hmm.. scroll_run_hook is also called from two redisplay optimizations in xdisp.c, so those will need to be disabled as well. Too bad. But maybe we can make them work if we consider the background image to be scrolled together with the text? "all we need" is to insert a slice of the same image from below or from above, depending on the scrolling direction. Btw, what happens when text is scrolled horizontally? Is this only going to work with fixed images? Then I guess features like showing vertical lines as indentation indicators, like those here: https://techpress.net/how-to-show-hide-indent-dots-in-vscode/ will not be possible? > +get_all_live_windows (struct window *w, struct window **dest) > +{ > + if (WINDOW_LEAF_P (w)) > + { You could perhaps extend window_loop to do whatever the callers of this function do Thanks for working on this.