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

[Eli Zaretskii]

> From: Alex Gramiak <address@hidden>
> Cc: address@hidden
> Date: Fri, 12 Apr 2019 13:50:01 -0600
> 
> 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)))

That could be OK, except that FRAME_MSDOS_P has the same problem as
FRAME_W32_P etc.: it is only defined for a single backend.

But if we want a single definition of FRAME_WINDOW_P, why not just
look at the output_method member and test that instead?  Maybe even
make it a bit mask, so a test is faster?

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

Not sure what that means, please elaborate.

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

It's okay to add such a comment, although the _P part of the name,
which stands for "Predicate", is supposed to say that already.

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

IMO, it's less than tiny.  Moving towards that goal one struct member
at a time makes no sense to me, because we are likely to discover that
other steps will need different changes that are incompatible with
this one.

Making Emacs able to use several window-systems in the same session is
a very worthy goal, but it must be a coherent set of changes made
according to some plan, and we should make those changes more or less
together, because otherwise there's a good chance we will be left with
only part of the changes and no real gain.  It happened before.

Thanks.