[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Renaming non-X x_* procedures in xdisp.c (and elsewhere)
From: |
Alex Gramiak |
Subject: |
Re: Renaming non-X x_* procedures in xdisp.c (and elsewhere) |
Date: |
Fri, 12 Apr 2019 13:50:01 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
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.