tooltip frame uses (class mono) when processing defface specs

tooltip frame uses (class mono) when processing defface specs

[Joe Wells]

When processing defface specs, the tooltip frame uses alternatives
that select the characteristic (class mono).  Alternatives that select
(class color) or (class grayscale) are not used.

Can this please be changed, or at least made customizable?

I am trying to get the folding mode of AUCTeX to display nicer
tooltips.  It would be nice if it could effectively use the
fontification of hidden text in tooltips.  Right now, standard faces
don't show well in the tooltips, because their mono version is used.
It would be a big help if the standard face definitions showed nicely
on tooltip frames.

(Yes, there are other issues that also would need to be handled, like
the way the tooltip-show function replaces the face of the message
string with the face tooltip.  But that is in Emacs Lisp, and hence
easier to fix, perhaps by making tooltip-show not do that if the
message has a particular property on it.)

-- 
Joe

Re: tooltip frame uses (class mono) when processing defface specs

[Joe Wells]

Joe Wells <jbw@macs.hw.ac.uk> writes:

> When processing defface specs, the tooltip frame uses alternatives
> that select the characteristic (class mono).  Alternatives that select
> (class color) or (class grayscale) are not used.

Here are some examples that illustrate this point.

The examples assume you are running Emacs on a color display, and that
you have loaded font-lock.el.

If you evaluate the following expression, you get some nicely colored
text in your tooltip:

  (x-show-tip (propertize "hello" 'face '(:foreground "red")))

In contrast, if you evaluate the following expression, you get black
text in your tooltip:

  (x-show-tip (propertize "hello" 'face 'font-lock-keyword-face))

You can see that font-lock-keyword-face normally has foreground color
"Purple" by evaluating this expression:

  (with-output-to-temp-buffer "xyzzy"
    (set-buffer standard-output)
    (insert (propertize "hello" 'face 'font-lock-keyword-face)))

This illustrates that the tooltip frame is using the mono version of
named faces, even though the tooltip frame is perfectly capable of
displaying colors.

-- 
Joe

> Can this please be changed, or at least made customizable?
>
> I am trying to get the folding mode of AUCTeX to display nicer
> tooltips.  It would be nice if it could effectively use the
> fontification of hidden text in tooltips.  Right now, standard faces
> don't show well in the tooltips, because their mono version is used.
> It would be a big help if the standard face definitions showed nicely
> on tooltip frames.
>
> (Yes, there are other issues that also would need to be handled, like
> the way the tooltip-show function replaces the face of the message
> string with the face tooltip.  But that is in Emacs Lisp, and hence
> easier to fix, perhaps by making tooltip-show not do that if the
> message has a particular property on it.)
>
> -- 
> Joe

Re: tooltip frame uses (class mono) when processing defface specs

[Richard Stallman]

    When processing defface specs, the tooltip frame uses alternatives
    that select the characteristic (class mono).  Alternatives that select
    (class color) or (class grayscale) are not used.

That is strange.  It ought to use whichever one fits the screen it is
on, right?

Re: tooltip frame uses (class mono) when processing defface specs

[Joe Wells]

Richard Stallman <rms@gnu.org> writes:

>     When processing defface specs, the tooltip frame uses
>     alternatives that select the characteristic (class mono).
>     Alternatives that select (class color) or (class grayscale) are
>     not used.
>
> That is strange.  It ought to use whichever one fits the screen it
> is on, right?

I had been guessing that this was a deliberate design choice (with
which I disagreed).  From what you say, it is rather a bug.

Anyway, the example expressions I sent should allow reproducing the
behavior I see.  Is this the case?

-- 
Joe

Re: tooltip frame uses (class mono) when processing defface specs

[Johan Bockgård]

Joe Wells <jbw@macs.hw.ac.uk> writes:

> When processing defface specs, the tooltip frame uses alternatives
> that select the characteristic (class mono).  Alternatives that select
> (class color) or (class grayscale) are not used.

FWIW, (class mono) isn't selected either.

This uses a yellow face:

    (defface bar
      '((((class color))      (:foreground "red"))
        (((class mono))       (:foreground "blue"))
        (((class grayscale))  (:foreground "green"))
        (t                    (:foreground "yellow")))
      "")

    (x-show-tip (propertize "hello" 'face 'bar))

-- 
Johan Bockgård

Re: tooltip frame uses (class mono) when processing defface specs

[Joe Wells]

Johan Bockgård writes:

> Joe Wells writes:
>
> > When processing defface specs, the tooltip frame uses alternatives
> > that select the characteristic (class mono).  Alternatives that
> > select (class color) or (class grayscale) are not used.
>
> FWIW, (class mono) isn't selected either.
>
> This uses a yellow face:
>
>     (defface bar
>       '((((class color))      (:foreground "red"))
>         (((class mono))       (:foreground "blue"))
>         (((class grayscale))  (:foreground "green"))
>         (t                    (:foreground "yellow")))
>       "")
>
>     (x-show-tip (propertize "hello" 'face 'bar))

Eeek!  That's much worse than I suspected.  I didn't test that because
the documentation says every frame must belong to one of the three
classes color, grayscale, or mono.  It didn't occur to me that tooltip
frames would violate that.

I think this makes the issue more clearly a bug.

-- 
Joe

Re: tooltip frame uses (class mono) when processing defface specs

[Richard Stallman]

    > When processing defface specs, the tooltip frame uses alternatives
    > that select the characteristic (class mono).  Alternatives that select
    > (class color) or (class grayscale) are not used.

    FWIW, (class mono) isn't selected either.

Can someone please debug this, then ack?

Re: tooltip frame uses (class mono) when processing defface specs

[Richard Stallman]

[I sent this message a week ago but did not get a response.]

    > When processing defface specs, the tooltip frame uses alternatives
    > that select the characteristic (class mono).  Alternatives that select
    > (class color) or (class grayscale) are not used.

    FWIW, (class mono) isn't selected either.

Can someone please debug this, then ack?

Re: tooltip frame uses (class mono) when processing defface specs

[Richard Stallman]

[I sent this message twice but did not get a response.]

    > When processing defface specs, the tooltip frame uses alternatives
    > that select the characteristic (class mono).  Alternatives that select
    > (class color) or (class grayscale) are not used.

    FWIW, (class mono) isn't selected either.

Can someone please debug this, then ack?

Re: tooltip frame uses (class mono) when processing defface specs

[John Paul Wallington]

Richard Stallman <rms@gnu.org> writes:

> [I sent this message twice but did not get a response.]
>
>     > When processing defface specs, the tooltip frame uses alternatives
>     > that select the characteristic (class mono).  Alternatives that select
>     > (class color) or (class grayscale) are not used.
>
>     FWIW, (class mono) isn't selected either.
>
> Can someone please debug this, then ack?

How about the following fix ?


2007-10-07  John Paul Wallington  <jpw@pobox.com>

	* xfns.c (x_create_tip_frame): Set the `display-type' frame
	parameter before setting up faces.

--- xfns.c	20 Sep 2007 22:18:47 +0100	1.691
+++ xfns.c	07 Oct 2007 17:26:40 +0100	
@@ -4946,7 +4946,23 @@
   if (NILP (Fframe_parameter (frame, intern ("tooltip"))))
     Fmodify_frame_parameters (frame, Fcons (Fcons (intern ("tooltip"), Qt),
 					    Qnil));
+  
+  /* Set the `display-type' frame parameter before setting up faces. */
+  {
+    Lisp_Object disptype;
+    
+    if (FRAME_X_DISPLAY_INFO (f)->n_planes == 1)
+      disptype = intern ("mono");
+    else if (FRAME_X_DISPLAY_INFO (f)->visual->class == GrayScale ||
+	     FRAME_X_DISPLAY_INFO (f)->visual->class == StaticGray)
+      disptype = intern ("grayscale");
+    else
+      disptype = intern ("color");
 
+    if (NILP (Fframe_parameter (frame, Qdisplay_type)))
+      Fmodify_frame_parameters (frame, Fcons (Fcons (Qdisplay_type, disptype),
+					      Qnil));
+  }
   /* Set up faces after all frame parameters are known.  This call
      also merges in face attributes specified for new frames.

Re: tooltip frame uses (class mono) when processing defface specs

[Glenn Morris]

John Paul Wallington wrote:

> How about the following fix ?

Works for me...

Re: tooltip frame uses (class mono) when processing defface specs

[Richard Stallman]

It looks plausible, but it has a drawback that it makes tooltip
frames work one way, while ordinary frames work a different way.
That is added complexity.

Can you investigate how things happen for ordinary frames, and then
see why they fail to happen the same way for tooltip frames?  That
might show the way to write a fix that would cause both kinds of
frames to be handled the same way.

One style point:

    +    else if (FRAME_X_DISPLAY_INFO (f)->visual->class == GrayScale ||
    +	     FRAME_X_DISPLAY_INFO (f)->visual->class == StaticGray)

Please break the line before the binary operator, not after.

Re: tooltip frame uses (class mono) when processing defface specs

[Glenn Morris]

Richard Stallman wrote:

> It looks plausible, but it has a drawback that it makes tooltip
> frames work one way, while ordinary frames work a different way.
> That is added complexity.
>
> Can you investigate how things happen for ordinary frames, and then
> see why they fail to happen the same way for tooltip frames?  That
> might show the way to write a fix that would cause both kinds of
> frames to be handled the same way.

It seems (to me) that for ordinary frames, more happens in Lisp,
whereas with tooltip frames, for whatever reason, more happens in C.
So it's probably not too simple to unify normal and tooltip frames in
this regard.

Looks to me as if for ordinary frames, x-create-frame-with-faces adds
the display-type frame parameter, when it calls
frame-set-background-mode (before going on to call
face-set-after-frame-default).

Re: tooltip frame uses (class mono) when processing defface specs

[Richard Stallman]

    Looks to me as if for ordinary frames, x-create-frame-with-faces adds
    the display-type frame parameter, when it calls
    frame-set-background-mode (before going on to call
    face-set-after-frame-default).

Is there any sensible way to handle the class for tooltip frames in a
fashion parallel to that?  If you find one, please implement that.
Otherwise, let's use the existing patch.