GNU bug report logs - #16992
feature request: background images

Previous Next

To reply to this bug, email your comments to 16992 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Englund <public <at> beloved.name>
To: bug-gnu-emacs <at> gnu.org
Subject: Feature request
Date: Wed, 12 Mar 2014 00:19:30 +0100

GNU Emacs cannot use background images AFAIK or anyone in #emacs at 
freenode.net for that matter. However, this can be done in XEmacs.

Can you please add this feature to people can personalize GNU Emacs with 
photos as desktop background of their beloved ones when they work.?


Best regards!

Message #10 received at 16992 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: David Englund <public <at> beloved.name>
Cc: 16992 <at> debbugs.gnu.org
Subject: Re: bug#16992: Feature request
Date: Wed, 12 Mar 2014 02:26:46 -0400

David Englund wrote:

> GNU Emacs cannot use background images AFAIK

I think there was a patch for this some years ago, but it was never
integrated (?). See eg

http://lists.gnu.org/archive/html/emacs-devel/2009-06/msg00485.html
http://lists.gnu.org/archive/html/emacs-devel/2003-08/msg00237.html

Maybe someone would like to resurrect it.


PS Please use a more meaningful subject line in future.

Message #15 received at 16992 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 20647 <at> debbugs.gnu.org, Tadashi Watanabe <wac <at> umiushi.org>,
 16992 <at> debbugs.gnu.org, David Englund <public <at> beloved.name>
Subject: Re: bug#16992: Feature request
Date: Tue, 04 Aug 2020 11:50:40 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> David Englund wrote:
>
>> GNU Emacs cannot use background images AFAIK
>
> I think there was a patch for this some years ago, but it was never
> integrated (?). See eg
>
> http://lists.gnu.org/archive/html/emacs-devel/2009-06/msg00485.html
> http://lists.gnu.org/archive/html/emacs-devel/2003-08/msg00237.html
>
> Maybe someone would like to resurrect it.

It's apparently being kept up to date:

https://github.com/wachikun/emacs_bgex

Unfortunately all the text surrounding it, and even the doc strings are
in Japanese, so reviewing the code is difficult.

I've Cc'd the author of bgex, because it would be nice to have
backgrounds in Emacs windows.

Tadashi -- would you be interested in integrating the code into Emacs?
If that's the case, translating it into English would be a useful first
step.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #18 received at 16992 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Tadashi Watanabe <twacc2020 <at> gmail.com>
Cc: 20647 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>,
 Tadashi Watanabe <wac <at> umiushi.org>, 16992 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>, David Englund <public <at> beloved.name>
Subject: Re: bug#16992: feature request: background images
Date: Fri, 5 Nov 2021 06:42:28 -0700

Hi Tadashi Watanabe,

I noticed that you have recently updated your e-mail address in the
bgex.el file on https://github.com/wachikun/emacs_bgex

We have discussed if it would be possible to integrate the "bgex" patch
into Emacs itself.  We think the feature is useful.  Would you be
interested in that?

See the previous discussion below, or here:

    https://debbugs.gnu.org/20647

Thanks in advance.

Best regards,
Stefan Kangas

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Glenn Morris <rgm <at> gnu.org> writes:
>
>> David Englund wrote:
>>
>>> GNU Emacs cannot use background images AFAIK
>>
>> I think there was a patch for this some years ago, but it was never
>> integrated (?). See eg
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2009-06/msg00485.html
>> http://lists.gnu.org/archive/html/emacs-devel/2003-08/msg00237.html
>>
>> Maybe someone would like to resurrect it.
>
> It's apparently being kept up to date:
>
> https://github.com/wachikun/emacs_bgex
>
> Unfortunately all the text surrounding it, and even the doc strings are
> in Japanese, so reviewing the code is difficult.
>
> I've Cc'd the author of bgex, because it would be nice to have
> backgrounds in Emacs windows.
>
> Tadashi -- would you be interested in integrating the code into Emacs?
> If that's the case, translating it into English would be a useful first
> step.

Message #21 received at 16992 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: 16992 <at> debbugs.gnu.org
Subject: feature request: background images
Date: Wed, 6 Nov 2024 23:34:43 +0100

Hello,

I have a patch almost ready to add background images for frames.  It has 
support only for X11+cairo and MS-Windows. I would like to have it 
reviewed before adding more variants, if that's ok.

I am planning to also draw informational UI elements into the background 
(with or without an image), such us fill column indicator, maybe indent 
lines, but again only if the implementation looks ok.

Message #24 received at 16992 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Cecilio Pardo <cpardo <at> imayhem.com>, 16992 <at> debbugs.gnu.org
Subject: Re: bug#16992: feature request: background images
Date: Wed, 6 Nov 2024 17:43:08 -0800

Cecilio Pardo <cpardo <at> imayhem.com> writes:

> Hello,
>
> I have a patch almost ready to add background images for frames.  It has
> support only for X11+cairo and MS-Windows. I would like to have it
> reviewed before adding more variants, if that's ok.
>
> I am planning to also draw informational UI elements into the background
> (with or without an image), such us fill column indicator, maybe indent
> lines, but again only if the implementation looks ok.

You forgot to attach the patch, I think?

Message #27 received at 16992 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 16992 <at> debbugs.gnu.org
Subject: Re: bug#16992: feature request: background images
Date: Thu, 07 Nov 2024 08:04:01 +0200

> Date: Wed, 6 Nov 2024 23:34:43 +0100
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> Hello,
> 
> I have a patch almost ready to add background images for frames.  It has 
> support only for X11+cairo and MS-Windows. I would like to have it 
> reviewed before adding more variants, if that's ok.
> 
> I am planning to also draw informational UI elements into the background 
> (with or without an image), such us fill column indicator, maybe indent 
> lines, but again only if the implementation looks ok.

Yes, it's okay to post partial changesets for review.

For the second part, I think this is a very welcome and long-desired
feature, so I suggest that we discuss its projected abilities and the
way it will be exposed to Lisp before you finalize the implementation.
There are quite a few potential features in Emacs which could be based
on something like that, and are basically blocked by our current
inability to do it, so IMO we should at least have a more-or-less full
list of those client features before us, as a prerequisite for
discussing the implementation.

Thanks!

Message #30 received at 16992 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Stefan Kangas <stefankangas <at> gmail.com>, 16992 <at> debbugs.gnu.org
Subject: Re: bug#16992: feature request: background images
Date: Thu, 7 Nov 2024 07:46:51 +0100

On 07/11/2024 2:43, Stefan Kangas wrote:
> Cecilio Pardo <cpardo <at> imayhem.com> writes:
> 
>> Hello,
>>
>> I have a patch almost ready to add background images for frames.  It has
>> support only for X11+cairo and MS-Windows. I would like to have it
>> reviewed before adding more variants, if that's ok.
>>
>> I am planning to also draw informational UI elements into the background
>> (with or without an image), such us fill column indicator, maybe indent
>> lines, but again only if the implementation looks ok.
> 
> You forgot to attach the patch, I think?

It is almost(TM) ready.

Message #33 received at 16992 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16992 <at> debbugs.gnu.org
Subject: Re: bug#16992: feature request: background images
Date: Fri, 8 Nov 2024 14:59:20 +0100

[Message part 1 (text/plain, inline)]

On 07/11/2024 7:04, Eli Zaretskii wrote:

> Yes, it's okay to post partial changesets for review.

Here is the incomplete patch that implements background images.

This should build and work for x+cairo and w32 (both mingw64 and
mingw.org's)

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))

There are new fields in the frame struct that control general activation
(background_policy), and the image to use (background_image).

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.

Also, in this patch I am drawing a red line to mark the current
fill-column value for each window, to show how it would work.

The simple frame image code would not change much from where it is:
would add offsets, and more backends, and more points on the code that
may clear the background.

Right now, the background is cleared normally, and then the image is
painted over if the rect was cleared with the frame's background
pixel. So, frames with colored background will work. I haven't tested
yet with a default font that has a background different from the frame's
color.

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.

I attach a couple of screenshots to see what to expect.

[0001-Support-for-background-images-on-frames.patch (text/plain, attachment)]

[emacs_R5JevGsu5Z.png (image/png, attachment)]

[msrdc_mtQ0HAdC5U.png (image/png, attachment)]

Message #36 received at 16992 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 16992 <at> debbugs.gnu.org
Subject: Re: bug#16992: feature request: background images
Date: Fri, 08 Nov 2024 17:46:10 +0200

> Date: Fri, 8 Nov 2024 14:59:20 +0100
> Cc: 16992 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> 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.

Message #39 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#16992: feature request: background images
Date: Fri, 8 Nov 2024 17:42:48 +0100

On 08/11/2024 16:46, Eli Zaretskii wrote:

> 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?

No, the background image (if present) is drawn first, then 'dynamic' 
things like the indicator are drawn over, with the corresponding drawing 
api. We are doing both things. In the patch, the fill-column indicator 
line is drawn by looking directly at the value of fill_column. But I 
think it would be better to allow lisp to define multiple vertical 
lines, with the desired position.

>> 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?

Yes, I will add x/y offsets, to put it anywhere.

>> 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.

We can add scrolling images, sure. I think we should do both types then.

> Btw, what happens when text is scrolled horizontally?

Nothing special. Besides redrawing everything.

> 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?

Yes. Those are not part of the image. We use the same mechanism to draw 
on the background, but they are independent. We can use them without 
background images at all.

Some of these things are easy to do, like the fill indicator, which 
doesn't depend on the contents of the buffer. Indentation lines are much 
more complex.

If you find the mechanism to draw on the background acceptable, I can 
work on a first version of that.

>> +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

Ok, thanks.

Message #42 received at 16992 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 16992 <at> debbugs.gnu.org
Subject: Re: bug#16992: feature request: background images
Date: Fri, 08 Nov 2024 20:50:35 +0200

> Date: Fri, 8 Nov 2024 17:42:48 +0100
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 08/11/2024 16:46, Eli Zaretskii wrote:
> 
> > 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?
> 
> No, the background image (if present) is drawn first, then 'dynamic' 
> things like the indicator are drawn over, with the corresponding drawing 
> api. We are doing both things. In the patch, the fill-column indicator 
> line is drawn by looking directly at the value of fill_column. But I 
> think it would be better to allow lisp to define multiple vertical 
> lines, with the desired position.

So what is the Lisp API for drawing those "dynamic" things?  AFAIU,
you've only shown the API to set a single static background image.

> > Btw, what happens when text is scrolled horizontally?
> 
> Nothing special. Besides redrawing everything.

Is the background image scrolled or isn't it?

> > 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?
> 
> Yes. Those are not part of the image. We use the same mechanism to draw 
> on the background, but they are independent. We can use them without 
> background images at all.
> 
> Some of these things are easy to do, like the fill indicator, which 
> doesn't depend on the contents of the buffer. Indentation lines are much 
> more complex.

Those "dynamic" drawings are the most wanted feature that is currently
missing.  And the challenge is to implement them in a way that won't
make redisplay significantly slower, e.g. due to disabled
optimizations (like scrolling_window).

Message #45 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#16992: feature request: background images
Date: Fri, 8 Nov 2024 20:20:31 +0100

On 08/11/2024 19:50, Eli Zaretskii wrote:
> So what is the Lisp API for drawing those "dynamic" things?  AFAIU,
> you've only shown the API to set a single static background image.

There is no lisp api yet. In this example the fill-column line is drawn 
always, in the part that iterates through the windows.

> Is the background image scrolled or isn't it?

No. The background image is always fixed at this point.

> Those "dynamic" drawings are the most wanted feature that is currently
> missing.  And the challenge is to implement them in a way that won't
> make redisplay significantly slower, e.g. due to disabled
> optimizations (like scrolling_window).

Then let's drop the image thing for now and focus on this.

The two use cases I have right now imply just a series of vertical lines:

- Lines fixed One to an x coordinate with an infinite height, for 
fill-column.
- Segments distributed through the window for the indent-lines.

We could have buffer local variables to define these lines.

What other features should we consider? Should we open a new bug report 
to discuss this?

Message #48 received at 16992 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 16992 <at> debbugs.gnu.org
Subject: Re: bug#16992: feature request: background images
Date: Sat, 09 Nov 2024 09:44:39 +0200

> Date: Fri, 8 Nov 2024 20:20:31 +0100
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 08/11/2024 19:50, Eli Zaretskii wrote:
> > So what is the Lisp API for drawing those "dynamic" things?  AFAIU,
> > you've only shown the API to set a single static background image.
> 
> There is no lisp api yet. In this example the fill-column line is drawn 
> always, in the part that iterates through the windows.
> 
> > Is the background image scrolled or isn't it?
> 
> No. The background image is always fixed at this point.

I could see use cases for optionally scrolling the background image as
well.

> > Those "dynamic" drawings are the most wanted feature that is currently
> > missing.  And the challenge is to implement them in a way that won't
> > make redisplay significantly slower, e.g. due to disabled
> > optimizations (like scrolling_window).
> 
> Then let's drop the image thing for now and focus on this.

We don't have to drop the background image feature.  It has its place,
IMO.  But I think we should not consider it as a candidate for
implementing dynamic drawings such as fill-column indicator.  That
should be a separate feature.

> The two use cases I have right now imply just a series of vertical lines:
> 
> - Lines fixed One to an x coordinate with an infinite height, for 
> fill-column.

It is not fixed because its X coordinate is controlled from Lisp.  In
addition, if a buffer mixes LTR and RTL paragraphs, the indicator is
shown sometimes on the right and sometimes on the left (because
columns are counted right-to-left in an RTL paragraph).

> - Segments distributed through the window for the indent-lines.
> 
> We could have buffer local variables to define these lines.

Yes.

> What other features should we consider?

Anything that needs some image to be drawn which partially or fully
overlaps the usual buffer/string display.

> Should we open a new bug report to discuss this?

Probably.  And I suggest to ask a question on emacs-devel.  Over the
years, there were quite a few requests for something like this, and
there are several optional (mostly 3rd-party) packages which try to do
this in Lisp (which require very complex Lisp code, and IMO look
clunky and even unprofessional), so asking a question might bring
additional interesting ideas for using this kind of functionality.

Btw, all of these will need some way of enabling at least some
redisplay optimizations, and at least for images which scroll together
with the buffer that should be possible.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.