GNU bug report logs - #75930
30.0.92; Setting default frame background color messes up mouse pointer

Previous Next

To reply to this bug, email your comments to 75930 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: Lars Rustand <rustand.lars <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.92; Setting default frame background color messes up mouse
 pointer
Date: Wed, 29 Jan 2025 17:36:18 +0100

Starting Emacs with the --background-color argument results in the contour
of the mouse pointer being set to that color when it is hovering over
Emacs.

This also happens if setting the background color through
default-frame-alist in early-init.el.

Setting the background color on startup through either
initial-frame-alist or window-system-default-frame-alist works as
expected, and does not change the mouse pointer.

Changing the background color of the frame at a later time, either by
calling set-background-color or by loading a theme does not change the
mouse pointer, whether that mouse pointer has already been modified by
Emacs during startup or not.

I am able to reproduce the behaviour in a clean Emacs using -Q.

The easiest way to reproduce is through this command:

    emacs -Q --background-color "#ff0000" --eval '(set-background-color "#000000")'

The results of the above command will be an Emacs frame with a black
background, and the mouse pointer will have a red contour when hovering
over that frame.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Rustand <rustand.lars <at> gmail.com>
Cc: 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92;
 Setting default frame background color messes up mouse pointer
Date: Wed, 29 Jan 2025 20:50:37 +0200

> From: Lars Rustand <rustand.lars <at> gmail.com>
> Date: Wed, 29 Jan 2025 17:36:18 +0100
> 
> 
> Starting Emacs with the --background-color argument results in the contour
> of the mouse pointer being set to that color when it is hovering over
> Emacs.
> 
> This also happens if setting the background color through
> default-frame-alist in early-init.el.
> 
> Setting the background color on startup through either
> initial-frame-alist or window-system-default-frame-alist works as
> expected, and does not change the mouse pointer.
> 
> Changing the background color of the frame at a later time, either by
> calling set-background-color or by loading a theme does not change the
> mouse pointer, whether that mouse pointer has already been modified by
> Emacs during startup or not.
> 
> I am able to reproduce the behaviour in a clean Emacs using -Q.
> 
> The easiest way to reproduce is through this command:
> 
>     emacs -Q --background-color "#ff0000" --eval '(set-background-color "#000000")'
> 
> The results of the above command will be an Emacs frame with a black
> background, and the mouse pointer will have a red contour when hovering
> over that frame.

Thanks, but I cannot reproduce this with the latest emacs-30 branch.
Please show all of the data collected by "M-x report-emacs-bug" about
your system and Emacs build configuration, perhaps what you see is
specific to some particular build.

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

From: rustand.lars <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Wed, 29 Jan 2025 20:49:37 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:
> Thanks, but I cannot reproduce this with the latest emacs-30 branch.
> Please show all of the data collected by "M-x report-emacs-bug" about
> your system and Emacs build configuration, perhaps what you see is
> specific to some particular build.

Sure I'll post it below. I'm posting the output as shown in emacs -Q,
since the bug isn't related to anything from my config/installed
packages.

I don't think this is related to a specific build, since it looks like
the bug has been present since at least 2018:
https://github.com/ch11ng/exwm/issues/513

Something that might be relevant is that I don't use any desktop
environment or login manager, but instead start my window manager
directly using startx. (The window manager I usually use is Emacs with
EXWM, but I have verified that I can reproduce from i3wm as well.)

I think desktop environments are likely to also meddle with the mouse
pointer, so if you are running one of those it will probably
mask/override the behaviour I'm seeing.



Data from "M-x report-emacs-bug" follows:
------

In GNU Emacs 30.0.92 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.41, cairo version 1.18.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101014
System Description: Guix System

Configured using:
 'configure
 CONFIG_SHELL=/gnu/store/6nqyia3ra10sgd1ppzk2047ncbzjwhff-bash-minimal-5.1.16/bin/bash
 SHELL=/gnu/store/6nqyia3ra10sgd1ppzk2047ncbzjwhff-bash-minimal-5.1.16/bin/bash
 --prefix=/gnu/store/ml6xyl3py6hqfdps2sypdi7s212y7k02-emacs-next-30.0.92-0.881d593
 --enable-fast-install --with-cairo --with-modules
 --with-native-compilation=aot --disable-build-details'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $EMACSLOADPATH: /home/lars/.guix-home/profile/share/emacs/site-lisp:/gnu/store/ml6xyl3py6hqfdps2sypdi7s212y7k02-emacs-next-30.0.92-0.881d593/share/emacs/30.0.92/lisp
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
native-compile emacs)

Memory information:
((conses 16 49646 9153) (symbols 48 5370 0) (strings 32 14312 2738)
 (string-bytes 1 538728) (vectors 16 9056)
 (vector-slots 8 126799 10092) (floats 8 22 24) (intervals 56 355 0)
 (buffers 992 12))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rustand.lars <at> gmail.com
Cc: 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Wed, 29 Jan 2025 21:58:44 +0200

> From: rustand.lars <at> gmail.com
> Cc: 75930 <at> debbugs.gnu.org
> Date: Wed, 29 Jan 2025 20:49:37 +0100
> 
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > Thanks, but I cannot reproduce this with the latest emacs-30 branch.
> > Please show all of the data collected by "M-x report-emacs-bug" about
> > your system and Emacs build configuration, perhaps what you see is
> > specific to some particular build.
> 
> Sure I'll post it below. I'm posting the output as shown in emacs -Q,
> since the bug isn't related to anything from my config/installed
> packages.
> 
> I don't think this is related to a specific build, since it looks like
> the bug has been present since at least 2018:
> https://github.com/ch11ng/exwm/issues/513
> 
> Something that might be relevant is that I don't use any desktop
> environment or login manager, but instead start my window manager
> directly using startx. (The window manager I usually use is Emacs with
> EXWM, but I have verified that I can reproduce from i3wm as well.)
> 
> I think desktop environments are likely to also meddle with the mouse
> pointer, so if you are running one of those it will probably
> mask/override the behaviour I'm seeing.
> 
> 
> 
> Data from "M-x report-emacs-bug" follows:

Thanks.  I wonder whether this is window-manager specific, even if not
exwm-specific

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

From: rustand.lars <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Wed, 29 Jan 2025 23:25:47 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks.  I wonder whether this is window-manager specific, even if not
> exwm-specific

I installed the GDM login manager and the gnome-shell desktop
environment to test your hypothesis. I observe the same behaviour there.

Even if it was "window-manager specific" as you say, I think that is a
backwards way of thinking about it. This is happening in a *minimal*
configuration where Emacs is running directly under X.

Having third-party programs hide the issue by taking control over the
theming of the mouse pointer shouldn't be the base case here.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rustand.lars <at> gmail.com, Po Lu <luangruo <at> yahoo.com>
Cc: 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Thu, 30 Jan 2025 08:17:10 +0200

> From: rustand.lars <at> gmail.com
> Cc: 75930 <at> debbugs.gnu.org
> Date: Wed, 29 Jan 2025 23:25:47 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Thanks.  I wonder whether this is window-manager specific, even if not
> > exwm-specific
> 
> I installed the GDM login manager and the gnome-shell desktop
> environment to test your hypothesis. I observe the same behaviour there.
> 
> Even if it was "window-manager specific" as you say, I think that is a
> backwards way of thinking about it. This is happening in a *minimal*
> configuration where Emacs is running directly under X.

The thing is, I cannot find where this setting of the border happens
in our code.  It seems to be the consequence of setting the frame's
background mode, which happens when you set the background color, but
that's where the track went cold for me, probably because I don't know
enough about the X11 graphics.  I hope someone else will be able to
point out where we cause that border to appear, and then a solution
might be found.

Po Lu, any suggestions or ideas?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rustand.lars <at> gmail.com, 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Thu, 30 Jan 2025 15:19:22 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: rustand.lars <at> gmail.com
>> Cc: 75930 <at> debbugs.gnu.org
>> Date: Wed, 29 Jan 2025 23:25:47 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Thanks.  I wonder whether this is window-manager specific, even if not
>> > exwm-specific
>> 
>> I installed the GDM login manager and the gnome-shell desktop
>> environment to test your hypothesis. I observe the same behaviour there.
>> 
>> Even if it was "window-manager specific" as you say, I think that is a
>> backwards way of thinking about it. This is happening in a *minimal*
>> configuration where Emacs is running directly under X.
>
> The thing is, I cannot find where this setting of the border happens
> in our code.  It seems to be the consequence of setting the frame's
> background mode, which happens when you set the background color, but
> that's where the track went cold for me, probably because I don't know
> enough about the X11 graphics.  I hope someone else will be able to
> point out where we cause that border to appear, and then a solution
> might be found.
>
> Po Lu, any suggestions or ideas?

Set a breakpoint on x_set_mouse_color, perhaps?

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

From: rustand.lars <at> gmail.com
To: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Thu, 30 Jan 2025 22:04:31 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> The thing is, I cannot find where this setting of the border happens
>> in our code.  It seems to be the consequence of setting the frame's
>> background mode, which happens when you set the background color, but
>> that's where the track went cold for me, probably because I don't know
>> enough about the X11 graphics.  I hope someone else will be able to
>> point out where we cause that border to appear, and then a solution
>> might be found.
>>
>> Po Lu, any suggestions or ideas?
>
> Set a breakpoint on x_set_mouse_color, perhaps?

I don't think a breakpoint will be necessary, I just popped in and had a
look at x_set_mouse_color, and it shows quite clearly that it does
explicitly do what I experience.

First it sets mask_color to the frame background near the start of the
function:

  unsigned long pixel = x_decode_color (f, arg, BLACK_PIX_DEFAULT (f));
  unsigned long mask_color = FRAME_BACKGROUND_PIXEL (f);


Then a bit further down it does this:

    XColor colors[2]; /* 0=foreground, 1=background */

    colors[0].pixel = x->mouse_pixel;
    colors[1].pixel = mask_color;
    x_query_colors (f, colors, 2);

    for (i = 0; i < mouse_cursor_max; i++)
      XRecolorCursor (dpy, cursor_data.cursor[i], &colors[0], &colors[1]);


So it seems that x_set_mouse_color always sets the mouse pointer border
color to the frame background. However, the foreground color defaults to
BLACK_PIX_DEFAULT.

This makes reproducing the bug even simpler, as it can now be done
multiple times from within Emacs without having to restart and passing
arguments to it.

This sequence of commands will do the same thing as the reproduction
steps I gave in the first message:

  (set-background-color "#ff0000")
  (set-mouse-color "#000000")
  (set-background-color "#000000")

Technically, the only line needed is the set-mouse-color one, but
changing the background before and after makes it easier to see.


A slightly different question is of course why it even calls
x_set_mouse_color on startup in the first place, when there is no custom
mouse color configured anywhere. The default behaviour should surely be
to not explicitly set the mouse color unless a color has been specified.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rustand.lars <at> gmail.com
Cc: luangruo <at> yahoo.com, 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Fri, 31 Jan 2025 09:11:15 +0200

> From: rustand.lars <at> gmail.com
> Cc: 75930 <at> debbugs.gnu.org
> Date: Thu, 30 Jan 2025 22:04:31 +0100
> 
> 
> Po Lu <luangruo <at> yahoo.com> writes:
> 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >> The thing is, I cannot find where this setting of the border happens
> >> in our code.  It seems to be the consequence of setting the frame's
> >> background mode, which happens when you set the background color, but
> >> that's where the track went cold for me, probably because I don't know
> >> enough about the X11 graphics.  I hope someone else will be able to
> >> point out where we cause that border to appear, and then a solution
> >> might be found.
> >>
> >> Po Lu, any suggestions or ideas?
> >
> > Set a breakpoint on x_set_mouse_color, perhaps?
> 
> I don't think a breakpoint will be necessary, I just popped in and had a
> look at x_set_mouse_color, and it shows quite clearly that it does
> explicitly do what I experience.
> 
> First it sets mask_color to the frame background near the start of the
> function:
> 
>   unsigned long pixel = x_decode_color (f, arg, BLACK_PIX_DEFAULT (f));
>   unsigned long mask_color = FRAME_BACKGROUND_PIXEL (f);
> 
> 
> Then a bit further down it does this:
> 
>     XColor colors[2]; /* 0=foreground, 1=background */
> 
>     colors[0].pixel = x->mouse_pixel;
>     colors[1].pixel = mask_color;
>     x_query_colors (f, colors, 2);
> 
>     for (i = 0; i < mouse_cursor_max; i++)
>       XRecolorCursor (dpy, cursor_data.cursor[i], &colors[0], &colors[1]);
> 
> 
> So it seems that x_set_mouse_color always sets the mouse pointer border
> color to the frame background. However, the foreground color defaults to
> BLACK_PIX_DEFAULT.

So now I'm confused: why is this a bug?

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

From: Lars Rustand <rustand.lars <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Sat, 01 Feb 2025 00:14:47 +0100

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

Eli Zaretskii <eliz <at> gnu.org> writes:
>
> So now I'm confused: why is this a bug?

I don't know why you are suddenly confused, because the description of
the bug has not changed. I have simply located the exact parts of the
code responsible for (one half of) the problem, i.e. the cause of the
mouse pointer border color being set to the frame background color.

Maybe my description of the issue I observe has not been clear
enough. Since you have not seen it first-hand, I attach an image which
illustrates the difference in mouse pointer caused by setting the
emacs frame background via the --background argument.

(I don't know how well image attachments work, if at all, on the mailing
list, so I apologize if the image does not make it through. Please let
me know if it doesn't reach you.)

The pointer to the left is how it normally looks, when emacs has not
modified it and the original Xorg pointer is still intact. As you can see
it is very easily visible, even against a dark background, thanks to
the border color.

The pointer on the right is the result of setting the frame background
color through the --background argument. As you can see the pointer is
now much less visible, since the border around the pointer is the exact
same color as the frame background.

Note that in neither of the examples have I set any custom mouse color,
so I would expect it to remain unchanged in both.



After finding the code I pointed to in my previous message, I realized
that this is in fact a two-part problem.

Part 1 is that x_set_mouse_color incorrectly uses the background color
of the current (or default?) frame as the color of the border/outline
of the mouse pointer. This makes that border in effect become
completely invisible when hovering over the emacs frame, which can make
the mouse pointer very hard to see.

Part 2 is that the act of setting a default frame background color
causes x_set_mouse_color to even be called in the first place. The mouse
color should obviously not be changed as a side effect of changing the
frame background color. These are two very different things that has
nothing to do with eachother.


I have identified the cause of part 1, but I have not (yet) found the
cause of part 2.

[pointers-sideby-side.png (image/png, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Rustand <rustand.lars <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Sat, 01 Feb 2025 09:41:11 +0800

Lars Rustand <rustand.lars <at> gmail.com> writes:

> Part 2 is that the act of setting a default frame background color
> causes x_set_mouse_color to even be called in the first place. The mouse
> color should obviously not be changed as a side effect of changing the
> frame background color. These are two very different things that has
> nothing to do with eachother.

Obviously they should, for otherwise the mouse cursor may become
invisible against the background of the frame.

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

From: Lars Rustand <rustand.lars <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Sat, 01 Feb 2025 08:51:31 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> Lars Rustand <rustand.lars <at> gmail.com> writes:
>
>> Part 2 is that the act of setting a default frame background color
>> causes x_set_mouse_color to even be called in the first place. The mouse
>> color should obviously not be changed as a side effect of changing the
>> frame background color. These are two very different things that has
>> nothing to do with eachother.
>
> Obviously they should, for otherwise the mouse cursor may become
> invisible against the background of the frame.

Your argument makes sense, but even if we accept that as correct, there
are multiple things wrong here. Why is there only two out of six
different ways to change the background that actually causes this to
happen?

(Even though I think your argument is valid, I still don't share your
opinon. I think this is unexpected behaviour from an X application. I
have never seen any other application which modifies my mouse pointer
colors. But I'll accept your premise for now.)

Given that you are concerned about making things invisible, the current
x_set_mouse_color *guarantees* that the border around the pointer
becomes invisible. A much more sensible default for this would be to use
the frame foreground color. Or pretty much *anything* else than the
frame background.

I hope we can agree that in my example image, the pointer which has not
been modified by emacs is much preferrable, and the one which has been
modified is verging on unusable. In a multi-monitor configuration with
many windows open, I find myself losing track of the mouse pointer and
having difficulty finding it again.


On a side note, even a black (unmodified) pointer is still highly
visible against a black frame background, as long as the contrasting
border around it is still present.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Rustand <rustand.lars <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Sat, 01 Feb 2025 16:28:08 +0800

Lars Rustand <rustand.lars <at> gmail.com> writes:

> Your argument makes sense, but even if we accept that as correct, there
> are multiple things wrong here. Why is there only two out of six
> different ways to change the background that actually causes this to
> happen?
>
> (Even though I think your argument is valid, I still don't share your
> opinon. I think this is unexpected behaviour from an X application. I
> have never seen any other application which modifies my mouse pointer
> colors. But I'll accept your premise for now.)
>
> Given that you are concerned about making things invisible, the current
> x_set_mouse_color *guarantees* that the border around the pointer
> becomes invisible. A much more sensible default for this would be to use
> the frame foreground color. Or pretty much *anything* else than the
> frame background.
>
> I hope we can agree that in my example image, the pointer which has not
> been modified by emacs is much preferrable, and the one which has been
> modified is verging on unusable. In a multi-monitor configuration with
> many windows open, I find myself losing track of the mouse pointer and
> having difficulty finding it again.
>
> On a side note, even a black (unmodified) pointer is still highly
> visible against a black frame background, as long as the contrasting
> border around it is still present.

This is only true of some X systems, not those for which this code was
initially designed.  But I am currently not horribly disposed to debug
the details of Emacs code when one of its maintainers is deliberately
turning a deaf ear to very reasonable requests on my part.  Namely, not
merging a branch for another month or so, once I have had a chance to
correct a number of its deficiencies.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Rustand <rustand.lars <at> gmail.com>
Cc: luangruo <at> yahoo.com, 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Sat, 01 Feb 2025 10:32:39 +0200

> From: Lars Rustand <rustand.lars <at> gmail.com>
> Cc: luangruo <at> yahoo.com, 75930 <at> debbugs.gnu.org
> Date: Sat, 01 Feb 2025 00:14:47 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > So now I'm confused: why is this a bug?
> 
> I don't know why you are suddenly confused, because the description of
> the bug has not changed. I have simply located the exact parts of the
> code responsible for (one half of) the problem, i.e. the cause of the
> mouse pointer border color being set to the frame background color.

I'm confused because what you found seems to mean Emacs works as
(should be) expected.  See below.

> After finding the code I pointed to in my previous message, I realized
> that this is in fact a two-part problem.
> 
> Part 1 is that x_set_mouse_color incorrectly uses the background color
> of the current (or default?) frame as the color of the border/outline
> of the mouse pointer. This makes that border in effect become
> completely invisible when hovering over the emacs frame, which can make
> the mouse pointer very hard to see.

What would you propose as an the alternative?

> Part 2 is that the act of setting a default frame background color
> causes x_set_mouse_color to even be called in the first place. The mouse
> color should obviously not be changed as a side effect of changing the
> frame background color. These are two very different things that has
> nothing to do with eachother.
> 
> 
> I have identified the cause of part 1, but I have not (yet) found the
> cause of part 2.

I think part 2 happens as part of frame-set-background-mode, as I
mentioned up-thread, and it makes sense to me.

What this might mean is that if you don't want the effect the original
recipe produces, you should call set-mouse-color again after
set-background-color.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rustand.lars <at> gmail.com, 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Sat, 01 Feb 2025 10:52:05 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  75930 <at> debbugs.gnu.org
> Date: Sat, 01 Feb 2025 09:41:11 +0800
> 
> Lars Rustand <rustand.lars <at> gmail.com> writes:
> 
> > Part 2 is that the act of setting a default frame background color
> > causes x_set_mouse_color to even be called in the first place. The mouse
> > color should obviously not be changed as a side effect of changing the
> > frame background color. These are two very different things that has
> > nothing to do with eachother.
> 
> Obviously they should, for otherwise the mouse cursor may become
> invisible against the background of the frame.

Exactly.  As mentioned, I think frame-set-background-mode does this.

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

From: Lars Rustand <rustand.lars <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>
Cc: 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Sat, 01 Feb 2025 14:18:16 +0100

TLDR; Can we avoid making the outline/border of the mouse pointer invisible?
----

Eli Zaretskii <eliz <at> gnu.org> writes:
 
>> I have identified the cause of part 1, but I have not (yet) found the
>> cause of part 2.
>
>I think part 2 happens as part of frame-set-background-mode, as I
>mentioned up-thread, and it makes sense to me.

Understood. I will accept this premise, even though I personally don't
fully agree with it.

>What this might mean is that if you don't want the effect the original
>recipe produces, you should call set-mouse-color again after
>set-background-color.

This suggestion seems to be based on a misunderstanding of which problem
I am actually reporting.

Unfortunately that will produce the exact result I am trying to avoid,
i.e. the mouse pointer on the right in my previously posted example
image, which has an invisible outline.

The last part of the original recipe (the --eval part) was only added
for demonstration purposes, to make the pointer outline clearly visible
against the background color to show clearly what is happening.

So, to be extra clear: the thing that I want to avoid is that passing
the --background-color argument causes the outline of the mouse pointer
to become invisible.

I guess this can be generalized to a slightly broader goal: Avoid making
the outline of the mouse pointer invisible, period. Or at the very
least, don't actively enforce that it becomes invisible like the current
x_set_mouse_color does.

>> Part 1 is that x_set_mouse_color incorrectly uses the background color
>> of the current (or default?) frame as the color of the border/outline
>> of the mouse pointer. This makes that border in effect become
>> completely invisible when hovering over the emacs frame, which can make
>> the mouse pointer very hard to see.
>
>What would you propose as an the alternative?

I realize that there is probably not a "perfect" solution to this, but I
can think of multiple ways that would be better than the current
situation.

1. Don't change the pointer outline color at all. Since set-mouse-color
   only accepts the foreground color as argument, I don't think it
   should change other colors than the one it is given as argument.
2. Apply the same logic as is currently used for the pointer foreground
   color. (See reference below)
3. Simply use the frame foreground color instead of the frame background
   color. This would be guaranteed to be visible against the background.
4. Use the "inverse" of the pointer foreground color.
5. Set it to either black or white, based on how light the pointer
   foreground color is.
6. Add a second (optional) argument to set-mouse-color, so the user is
   able to decide the color of the outline.

My preferred solution would be nr 1, possibly combined with 2 to avoid
leaving the outline color unchanged in cases where this would cause it
to be invisible.


The if-check (from x_set_mouse_color) referenced by point 2 above:

  /* Don't let pointers be invisible.  */
  if (mask_color == pixel)
    {
      x_free_colors (f, &pixel, 1);
      pixel = x_copy_color (f, FRAME_FOREGROUND_PIXEL (f));
    }


Po Lu <luangruo <at> yahoo.com> writes:

> But I am currently not horribly disposed to debug
> the details of Emacs code when one of its maintainers is deliberately
> turning a deaf ear to very reasonable requests on my part.  Namely, not
> merging a branch for another month or so, once I have had a chance to
> correct a number of its deficiencies.

I'm sorry to hear about this, but I hope this won't affect your
judgement when it comes to recognizing something as a bug or not. I
don't expect you to do the debugging for me, I'm willing to do all the
debugging and patching myself, as long as we can all agree about what
needs fixing, and what doesn't. In fact, I think I have all the details
I need in order to implement a solution (depending on which route we
want to go).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: luangruo <at> yahoo.com, Lars Rustand <rustand.lars <at> gmail.com>
Cc: 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Sat, 15 Feb 2025 13:19:37 +0200

Ping! Po Lu, any comments or suggestions?

> From: Lars Rustand <rustand.lars <at> gmail.com>
> Cc: 75930 <at> debbugs.gnu.org
> Date: Sat, 01 Feb 2025 14:18:16 +0100
> 
> 
> 
> TLDR; Can we avoid making the outline/border of the mouse pointer invisible?
> ----
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
>  
> >> I have identified the cause of part 1, but I have not (yet) found the
> >> cause of part 2.
> >
> >I think part 2 happens as part of frame-set-background-mode, as I
> >mentioned up-thread, and it makes sense to me.
> 
> Understood. I will accept this premise, even though I personally don't
> fully agree with it.
> 
> >What this might mean is that if you don't want the effect the original
> >recipe produces, you should call set-mouse-color again after
> >set-background-color.
> 
> This suggestion seems to be based on a misunderstanding of which problem
> I am actually reporting.
> 
> Unfortunately that will produce the exact result I am trying to avoid,
> i.e. the mouse pointer on the right in my previously posted example
> image, which has an invisible outline.
> 
> The last part of the original recipe (the --eval part) was only added
> for demonstration purposes, to make the pointer outline clearly visible
> against the background color to show clearly what is happening.
> 
> So, to be extra clear: the thing that I want to avoid is that passing
> the --background-color argument causes the outline of the mouse pointer
> to become invisible.
> 
> I guess this can be generalized to a slightly broader goal: Avoid making
> the outline of the mouse pointer invisible, period. Or at the very
> least, don't actively enforce that it becomes invisible like the current
> x_set_mouse_color does.
> 
> >> Part 1 is that x_set_mouse_color incorrectly uses the background color
> >> of the current (or default?) frame as the color of the border/outline
> >> of the mouse pointer. This makes that border in effect become
> >> completely invisible when hovering over the emacs frame, which can make
> >> the mouse pointer very hard to see.
> >
> >What would you propose as an the alternative?
> 
> I realize that there is probably not a "perfect" solution to this, but I
> can think of multiple ways that would be better than the current
> situation.
> 
> 1. Don't change the pointer outline color at all. Since set-mouse-color
>    only accepts the foreground color as argument, I don't think it
>    should change other colors than the one it is given as argument.
> 2. Apply the same logic as is currently used for the pointer foreground
>    color. (See reference below)
> 3. Simply use the frame foreground color instead of the frame background
>    color. This would be guaranteed to be visible against the background.
> 4. Use the "inverse" of the pointer foreground color.
> 5. Set it to either black or white, based on how light the pointer
>    foreground color is.
> 6. Add a second (optional) argument to set-mouse-color, so the user is
>    able to decide the color of the outline.
> 
> My preferred solution would be nr 1, possibly combined with 2 to avoid
> leaving the outline color unchanged in cases where this would cause it
> to be invisible.
> 
> 
> The if-check (from x_set_mouse_color) referenced by point 2 above:
> 
>   /* Don't let pointers be invisible.  */
>   if (mask_color == pixel)
>     {
>       x_free_colors (f, &pixel, 1);
>       pixel = x_copy_color (f, FRAME_FOREGROUND_PIXEL (f));
>     }
> 
> 
> Po Lu <luangruo <at> yahoo.com> writes:
> 
> > But I am currently not horribly disposed to debug
> > the details of Emacs code when one of its maintainers is deliberately
> > turning a deaf ear to very reasonable requests on my part.  Namely, not
> > merging a branch for another month or so, once I have had a chance to
> > correct a number of its deficiencies.
> 
> I'm sorry to hear about this, but I hope this won't affect your
> judgement when it comes to recognizing something as a bug or not. I
> don't expect you to do the debugging for me, I'm willing to do all the
> debugging and patching myself, as long as we can all agree about what
> needs fixing, and what doesn't. In fact, I think I have all the details
> I need in order to implement a solution (depending on which route we
> want to go).
> 

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Rustand <rustand.lars <at> gmail.com>, 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Sat, 15 Feb 2025 21:16:37 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Ping! Po Lu, any comments or suggestions?

I'd like more time to consider this.  As a rule I am loath to disturb
code that has existed for decades, as it was probably correct when it
was written and remains so in limited circumstances.

Previous Next

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