Re: Renaming non-X x_* procedures in xdisp.c (and elsewhere)

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex <agrambot@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 11 Apr 2019 13:07:44 -0600
> 
> I'm back to working on this now. I have a few disjointed questions, but
> for now I'd like to ask:
> 
> * What's your opinion on changing FRAME_WINDOW_P to basically a C
>   version of display-graphics-p? This would move toward using multiple
>   windowing systems simultaneously, and helps clear the intent of the
>   predicate. I searched and only found uses of it being used as a
>   boolean.

You submitted a separate patch for this, so let's discuss this issue
there.

> * To get rid of a few FRAME_X_WINDOW calls in frame.c and all of the
>   FRAME_X_OUTPUT (f)->* calls in xdisp.c I'm considering adding a new
>   function pointer interface frame_output_interface, which would allow
>   for a generic interface to common output_data elements. Would you be
>   open to this?  For example, the following:
> 
>     FRAME_X_OUTPUT (f)->nontext_cursor
> 
>   would be changed to something like:
> 
>     FRAME_OI (f)->get_nontext_cursor (f);
> 
>   And the FRAME_X_WINDOW calls in frame.c to:
> 
>     FRAME_OI (f)->have_native_window (f);

Why is this an improvement?  It will certainly make the code a tiny
bit slower, due to a function call overhead.  There's nothing wrong
with the above macros, except their names, which come from X.  If you
want to change the name to something window-system agnostic, that
might be OK (although again, not a significant improvement IMO), but
other than that, I see no reason, as having a function pointer doesn't
get us any closer to supporting several frame types than the current
code.

> * Why is the font structure within a frame's output_data instead of in
>   the frame itself?

Because TTY frames don't need it, I guess.