Re: Inconsistent margin background color in minibuffer

[Eli Zaretskii <eliz@gnu.org>]

> From: "Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr>
> Date: Tue, 30 Jul 2024 16:55:17 +0200
> 
> 
> I'm experimenting with the minibuffer and I get some problem setting the
> margin (not fringe) background color. Here is a simple example:
> 
> (defun setup-minibuffer ()
>   (setq-local truncate-lines t)
>   (set-window-margins nil 10 10)
>   (set-window-fringes nil 0 0)
>   (goto-char (point-min))
>   (face-remap-set-base 'default '(:background "#cccccc")))
> 
> (add-hook 'minibuffer-setup-hook #'setup-minibuffer)
> 
> (completing-read "Very long prompt: "
>                  nil nil nil
>    "Very long line that should trigger truncation (hopefully), else, reduce window width.")
> 
> When the point is at the start of the prompt, margin background color is
> white (default bg color I guess) but when the point is at the end of the
> entry, margin background color is "#cccccc".
> 
> Is that the expected behavior? If yes, how can I force the margin
> background color to use the remapped default face ?

It's a bug, and a very old one.  When the feature of showing
truncation/continuation glyphs on GUI frames was added to Emacs, we
failed to consider the case where there are display margins with
nothing in them (i.e., the margin area is empty) and the default face
is remapped.

I have now fixed that on the master branch.  While at that, I also
fixed a minor related inconsistency: the truncation/continuation
glyphs should use the remapped default face for their background (in
your case, the truncation glyphs should have the same background color
of "#cccccc"), not the default frame background.