[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Renaming non-X x_* procedures in xdisp.c (and elsewhere)
From: |
Eli Zaretskii |
Subject: |
Re: Renaming non-X x_* procedures in xdisp.c (and elsewhere) |
Date: |
Fri, 12 Apr 2019 22:03:06 +0300 |
> From: Alex <address@hidden>
> Cc: address@hidden
> 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.