Can we use FRAME_RIF to return a Lisp_Object result?

Can we use FRAME_RIF to return a Lisp_Object result?

[Keith David Bershatsky]

As part of the multiple fake cursors (22873) and crosshairs (17684) features that I am working on, I am obtaining the red / green / blue values for the buffer default background face by using platform specific functions within nsterm.m, xterm.c, and w32term.c.

I would like `FRAME_RIF (f)->calc_lsl_default_bg (w)` to return a Lisp_Object in the form of a vector consisting of 3 doubles.

All of the examples in redisplay_interface are void, which makes me think that a Lisp_Object result may not be supported.

I have been using window pointers to store the values for red, green and blue.  However, I would like to eliminate the need to use those window pointers in favor of FRAME_RIF returning a Lisp_Object result.  Is this okay to do, or is there a more appropriate way to get the result of those platform specific functions?


/* window.h */
/* Suffixes for the `mc` window pointer prefix. */
struct multiple_cursors
{
  * * *

  /* Values for the background color that are used to erase a glyphless cursor. */
  double bg_red, bg_green, bg_blue;

  * * *
};


/* nsterm.m */
static void
ns_calc_lsl_default_bg (struct window *w)
{
  struct frame *f = XFRAME (WINDOW_FRAME (w));
  /* The default face, possibly remapped. */
  struct face *default_face = FACE_FROM_ID (f, lookup_basic_face (f, DEFAULT_FACE_ID));
  NSColor *background_color = ns_lookup_indexed_color (default_face->background, f);
  EmacsCGFloat red, green, blue;
  * * *
  w->mc.bg_red = red;
  w->mc.bg_green = green;
  w->mc.bg_blue = blue;
  * * *
}


/* dispextern.h */

struct redisplay_interface
{
  /* Handlers for setting frame parameters.  */
  frame_parm_handler *frame_parm_handlers;

  * * * 

  void (*calc_lsl_default_bg) (struct window *w);

  * * *
};

Thanks,

Keith

Re: Can we use FRAME_RIF to return a Lisp_Object result?

[Eli Zaretskii]

> Date: Tue, 31 Oct 2017 11:44:02 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> As part of the multiple fake cursors (22873) and crosshairs (17684) features that I am working on, I am obtaining the red / green / blue values for the buffer default background face by using platform specific functions within nsterm.m, xterm.c, and w32term.c.
> 
> I would like `FRAME_RIF (f)->calc_lsl_default_bg (w)` to return a Lisp_Object in the form of a vector consisting of 3 doubles.
> 
> All of the examples in redisplay_interface are void, which makes me think that a Lisp_Object result may not be supported.
> 
> I have been using window pointers to store the values for red, green and blue.  However, I would like to eliminate the need to use those window pointers in favor of FRAME_RIF returning a Lisp_Object result.  Is this okay to do, or is there a more appropriate way to get the result of those platform specific functions?
> 
> 
> /* window.h */
> /* Suffixes for the `mc` window pointer prefix. */
> struct multiple_cursors
> {
>   * * *
> 
>   /* Values for the background color that are used to erase a glyphless cursor. */
>   double bg_red, bg_green, bg_blue;
> 
>   * * *
> };
> 
> 
> /* nsterm.m */
> static void
> ns_calc_lsl_default_bg (struct window *w)
> {
>   struct frame *f = XFRAME (WINDOW_FRAME (w));
>   /* The default face, possibly remapped. */
>   struct face *default_face = FACE_FROM_ID (f, lookup_basic_face (f, DEFAULT_FACE_ID));
>   NSColor *background_color = ns_lookup_indexed_color (default_face->background, f);
>   EmacsCGFloat red, green, blue;
>   * * *
>   w->mc.bg_red = red;
>   w->mc.bg_green = green;
>   w->mc.bg_blue = blue;
>   * * *
> }

I don't understand why you need a platform-dependent implementation
for this.  Given the face (obtained using FACE_FROM_ID as above), you
have its Lisp attributes in face->lface, and the foreground and
background pixels are then at lface[LFACE_FOREGROUND_INDEX] and
lface[LFACE_BACKGROUND_INDEX] respectively.  These are XColor values,
so getting the RGB components from them is trivial.

For frame's default face, you can do this even simpler: by using
FRAME_FOREGROUND_PIXEL and FRAME_BACKGROUND_PIXEL.

Am I missing something?

Re: Can we use FRAME_RIF to return a Lisp_Object result?

[Keith David Bershatsky]

Thank you, Eli.

Prior to just a few minutes ago when I read your comments, I had been unaware that it was possible to obtain the RGB for the default foreground/background (which might be remapped on a buffer local basis) from within xdisp.c absent using platform-dependent functions.  That misunderstanding was based (in large part) upon a layman's reading of the code looking for keywords such as "red", "green", "blue", and "RGB".  Because I found keywords of that nature in the platform-dependent areas of the code (nsterm.m, w32term.c, and xterm.c), I made the erroneous assumption mentioned above.

I look forward to using your examples and eliminating the erroneous platform-dependent implementations.

As always, your help is greatly appreciated!

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [10-31-2017 12:38:01] <31 Oct 2017 21:38:01 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> * * *
> 
> I don't understand why you need a platform-dependent implementation
> for this.  Given the face (obtained using FACE_FROM_ID as above), you
> have its Lisp attributes in face->lface, and the foreground and
> background pixels are then at lface[LFACE_FOREGROUND_INDEX] and
> lface[LFACE_BACKGROUND_INDEX] respectively.  These are XColor values,
> so getting the RGB components from them is trivial.
> 
> For frame's default face, you can do this even simpler: by using
> FRAME_FOREGROUND_PIXEL and FRAME_BACKGROUND_PIXEL.
> 
> Am I missing something?

Re: Can we use FRAME_RIF to return a Lisp_Object result?

[Eli Zaretskii]

> Date: Tue, 31 Oct 2017 12:59:02 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> Cc: emacs-devel@gnu.org
> 
> Prior to just a few minutes ago when I read your comments, I had been unaware that it was possible to obtain the RGB for the default foreground/background (which might be remapped on a buffer local basis) from within xdisp.c absent using platform-dependent functions.  That misunderstanding was based (in large part) upon a layman's reading of the code looking for keywords such as "red", "green", "blue", and "RGB".  Because I found keywords of that nature in the platform-dependent areas of the code (nsterm.m, w32term.c, and xterm.c), I made the erroneous assumption mentioned above.

If you want to understand how face colors are being managed and
manipulated in Emacs, you should read xfaces.c, not the other source
files.