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

[Alex Gramiak]

Eli Zaretskii <address@hidden> writes:

>> 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.

While the other patch is more related to this question than the topic of
this thread, that patch doesn't involve FRAME_WINDOW_P and is thus
separate from that patch as well.

The change I'd like to do to FRAME_WINDOW_P doesn't introduce
significant constructs like my other patch does.

It would introduce a tiny slowdown though. Here is the new version:

  #define FRAME_WINDOW_P(f) (!(FRAME_TERMINAL_P (f)
                              || FRAME_INITIAL_P (f)
                              || FRAME_MSDOS_P (f)))

Equivalently it would check for FRAME_{X,NS,W32}_P.

Or do you mean that you wouldn't accept such a patch without making the
entirety of Emacs multi-window-system capable? At the very least, I
believe there should be a comment by the definition of FRAME_WINDOW_P
that states not to use the return value as a non-boolean.

> 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.

Would it not get us closer due to not depending on the specific
output_data type and thus the positioning of the cursor elements in the
output_data struct? Of course it would only be a tiny step closer.

I suppose I'll replace the FRAME_X_WINDOW calls with FRAME_NATIVE_WINDOW
and FRAME_X_OUTPUT (in non-X contexts) with FRAME_OUTPUT_DATA for now.