bug#75930: 30.0.92; Setting default frame background color messes up mouse pointer

[Eli Zaretskii]

Ping! Po Lu, any comments or suggestions?

> From: Lars Rustand <rustand.lars@gmail.com>
> Cc: 75930@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@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@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).
>