bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Lars Ingebrigtsen
Dale Sedivec <[hidden email]> writes:

> The Emacs manual says[1], "the text shown under the cursor is drawn using
> the frame’s background color."  However, on the NS port, the foreground
> for text under the cursor seems to be taken from the face at point
> rather than the frame's background color.
>
> [1]: https://www.gnu.org/software/emacs/manual/html_node/emacs/Cursor-Display.html
>
> To illustrate this, start emacs -Q and eval:
>
>     (progn
>       (switch-to-buffer (generate-new-buffer "test"))
>       (insert (propertize "testing"
>                           'face '((:background "blue" :foreground "white"))))
>       (goto-char 1))

It's not just the NS port, apparently -- I get the same in Debian.

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



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Alan Third
On Mon, Sep 14, 2020 at 01:11:30AM +0200, Lars Ingebrigtsen wrote:

> Dale Sedivec <[hidden email]> writes:
>
> > The Emacs manual says[1], "the text shown under the cursor is drawn using
> > the frame’s background color."  However, on the NS port, the foreground
> > for text under the cursor seems to be taken from the face at point
> > rather than the frame's background color.
> >
> > [1]: https://www.gnu.org/software/emacs/manual/html_node/emacs/Cursor-Display.html
> >
> > To illustrate this, start emacs -Q and eval:
> >
> >     (progn
> >       (switch-to-buffer (generate-new-buffer "test"))
> >       (insert (propertize "testing"
> >                           'face '((:background "blue" :foreground "white"))))
> >       (goto-char 1))
>
> It's not just the NS port, apparently -- I get the same in Debian.

Now you mention it, I can see that the X ports use the face colours as
well...

xterm.c:1518
      xgcv.background = s->f->output_data.x->cursor_pixel;
      xgcv.foreground = s->face->background;
           ^               ^
--
Alan Third



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Date: Mon, 14 Sep 2020 01:49:43 +0200
> Cc: [hidden email], Dale Sedivec <[hidden email]>
>
> Alan Third <[hidden email]> writes:
>
> > Now you mention it, I can see that the X ports use the face colours as
> > well...
> >
> > xterm.c:1518
> >       xgcv.background = s->f->output_data.x->cursor_pixel;
> >       xgcv.foreground = s->face->background;
> >            ^               ^
>
> Yeah, it looks like it's been like that since at least the 90s.  So...
> the documentation is just wrong?

Yes, the documentation is inaccurate: it describes what happens when
the text at point uses the default face.  When the face is not the
default, we merge that face into the cursor face, and that is what you
see.

We should fix the documentation.



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Dale Sedivec-6
On Sep 14, 2020, at 09:52, Eli Zaretskii <[hidden email]> wrote:

>> From: Lars Ingebrigtsen <[hidden email]>
>> Date: Mon, 14 Sep 2020 01:49:43 +0200
>> Cc: [hidden email], Dale Sedivec <[hidden email]>
>>
>> Alan Third <[hidden email]> writes:
>>
>>> Now you mention it, I can see that the X ports use the face colours as
>>> well...
>>>
>>> xterm.c:1518
>>>      xgcv.background = s->f->output_data.x->cursor_pixel;
>>>      xgcv.foreground = s->face->background;
>>>           ^               ^
>>
>> Yeah, it looks like it's been like that since at least the 90s.  So...
>> the documentation is just wrong?
>
> Yes, the documentation is inaccurate: it describes what happens when
> the text at point uses the default face.  When the face is not the
> default, we merge that face into the cursor face, and that is what you
> see.
>
> We should fix the documentation.

Understood.  Would it be appropriate for me to open a separate bug for the problem of the text under the box cursor being nearly unreadable, as in my example?  Maybe allowing the cursor face's :foreground to be used in preference to the background of the face at point?

Dale


Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Lars Ingebrigtsen
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

>> > Now you mention it, I can see that the X ports use the face colours as
>> > well...
>> >
>> > xterm.c:1518
>> >       xgcv.background = s->f->output_data.x->cursor_pixel;
>> >       xgcv.foreground = s->face->background;
>> >            ^               ^
>>
>> Yeah, it looks like it's been like that since at least the 90s.  So...
>> the documentation is just wrong?
>
> Yes, the documentation is inaccurate: it describes what happens when
> the text at point uses the default face.  When the face is not the
> default, we merge that face into the cursor face, and that is what you
> see.
>
> We should fix the documentation.

Or should we fix the code?  As the example demonstrates, this makes some
of the inverse-blinked text difficult to read.  Presumably the colour
distance between the cursor and the default face's background is more
legible?

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



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Eli Zaretskii
In reply to this post by Dale Sedivec-6
> From: Dale Sedivec <[hidden email]>
> Date: Mon, 14 Sep 2020 17:10:30 -0500
> Cc: Lars Ingebrigtsen <[hidden email]>,
>  [hidden email],
>  [hidden email]
>
> > We should fix the documentation.
>
> Understood.  Would it be appropriate for me to open a separate bug for the problem of the text under the box cursor being nearly unreadable, as in my example?

Feel free.  I don't yet see how this could be solved, but a bug report
cannot hurt.

> Maybe allowing the cursor face's :foreground to be used in preference to the background of the face at point?

That'd be contrary to what Emacs does with faces in every other
situation, so I prefer not to consider such a solution, certainly not
as the first alternative.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Eli Zaretskii
In reply to this post by Lars Ingebrigtsen
> From: Lars Ingebrigtsen <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email]
> Date: Tue, 15 Sep 2020 14:22:20 +0200
>
> > We should fix the documentation.
>
> Or should we fix the code?  As the example demonstrates, this makes some
> of the inverse-blinked text difficult to read.

Any specific suggestions for a fix?

> Presumably the colour distance between the cursor and the default
> face's background is more legible?

If you imply that we should sometimes refuse to merge faces, I'd
object to that, since we never do such things anywhere.

Maybe it's enough to define (and handle) a distant-foreground color
for the cursor face?



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Eli Zaretskii
> Date: Tue, 15 Sep 2020 17:44:08 +0300
> From: Eli Zaretskii <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email]
>
> > Or should we fix the code?  As the example demonstrates, this makes some
> > of the inverse-blinked text difficult to read.
>
> Any specific suggestions for a fix?
>
> > Presumably the colour distance between the cursor and the default
> > face's background is more legible?
>
> If you imply that we should sometimes refuse to merge faces, I'd
> object to that, since we never do such things anywhere.
>
> Maybe it's enough to define (and handle) a distant-foreground color
> for the cursor face?

Oh, and of course the documentation should be fixed regardless, as it
is inaccurate, and will continue to be inaccurate even if we fix this
in some way.



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Lars Ingebrigtsen
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

>> Or should we fix the code?  As the example demonstrates, this makes some
>> of the inverse-blinked text difficult to read.
>
> Any specific suggestions for a fix?

That we do what the documentation suggests -- use the frame background
(i.e., the default face background) as the face foreground of the
character under point.

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



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email]
> Date: Thu, 17 Sep 2020 16:36:52 +0200
>
> > Any specific suggestions for a fix?
>
> That we do what the documentation suggests -- use the frame background
> (i.e., the default face background) as the face foreground of the
> character under point.

What if that character has a non-default foreground color?  If we
disregard it, all the characters will look the same when under the
cursor, regardless of their original face.

Besides, this is different from every other place in Emacs where we
have more than one source for face information: we always merge all
the faces.

So I cannot say I like this proposal.



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email]
> Date: Thu, 17 Sep 2020 17:06:31 +0200
>
> The character under point will have the cursor colour as the
> background colour, and it doesn't matter what the foreground colour
> of that character is: Today the foreground colour (when the cursor
> is over the character) is the character's background colour, but the
> proposal is to change that to use the default face's background
> colour instead.

I understand.  The result will be that every character under cursor
will look the same regardless of its original face colors.  Which is
both losing information and different from the face-merging we do
everywhere else.

The original problem, AFAIU, was not that we behave as we do, but that
the result is almost illegible in some situations.  The solution to
that doesn't have to be what you propose, it can be something else,
which doesn't ignore our usual face-merging.  We just need to use a
mechanism we have for this purpose: the distant-foreground color of a
face.



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Lars Ingebrigtsen
Eli Zaretskii <[hidden email]> writes:

> I understand.  The result will be that every character under cursor
> will look the same regardless of its original face colors.

Oh, I didn't think of that as an issue...  I mean, the cursor blinks (by
default), so...  does anybody care?

> Which is both losing information and different from the face-merging
> we do everywhere else.
>
> The original problem, AFAIU, was not that we behave as we do, but that
> the result is almost illegible in some situations.

Yup.

> The solution to that doesn't have to be what you propose, it can be
> something else, which doesn't ignore our usual face-merging.  We just
> need to use a mechanism we have for this purpose: the
> distant-foreground color of a face.

The vast majority of faces don't have a distant-foreground, I think?
And that's in relation to the region face, not the cursor?

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



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email]
> Date: Fri, 18 Sep 2020 13:06:16 +0200
>
> > The solution to that doesn't have to be what you propose, it can be
> > something else, which doesn't ignore our usual face-merging.  We just
> > need to use a mechanism we have for this purpose: the
> > distant-foreground color of a face.
>
> The vast majority of faces don't have a distant-foreground, I think?
> And that's in relation to the region face, not the cursor?

I thought to define it only for the cursor face.  And if that needs
some special treatment on the C level, it shouldn't be hard to tweak
that.



Reply | Threaded
Open this post in threaded view
|

bug#43381: 27.1.50; Maybe wrong cursor FG color in NS port

Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email]
> Date: Fri, 18 Sep 2020 15:07:05 +0200
>
> > I thought to define it only for the cursor face.  And if that needs
> > some special treatment on the C level, it shouldn't be hard to tweak
> > that.
>
> Ah, right...  but then that'd be used on all characters the cursor is
> over, no matter what the background colour of the cursor is?

No, only when the contrast with the other color is too low.