[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Renaming non-X x_* identifiers

From: Eli Zaretskii
Subject: Re: [PATCH] Renaming non-X x_* identifiers
Date: Mon, 15 Apr 2019 17:51:52 +0300

> From: Alex Gramiak <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Sun, 14 Apr 2019 11:34:22 -0600
> The calls should already be #ifdef'd; it's the declarations that would
> be #ifdef'd.
> > I thought those which don't need to be tested are available on both
> > GUI and TTY frames.
> I believe there are (currently) three categories:
> (a) Hooks implemented by all backends, which don't need to be tested.
> (b) Hooks implemented by only GUI frames, but occurring in branches that
> non-GUI frames are used. These have to be tested.
> (c) Hooks implemented by only GUI frames, and occurring in branches that
> only GUI frames are used, and are in a preprocessor conditional. These
> don't have to be (and some currently aren't) tested.

Thanks, now the issue is clear.

I think I'd prefer to treat (c) the same as (b), though, i.e. add the
tests where we don't have them, and leave the declarations visible in
all builds.  My reasoning is that the current situation is more or
less ad-hoc, and therefore some of the (c) could at some point become
(b).  If and when that happens, treating them the same will allow
easier rearrangement of the code.  By contrast, having such a modified
code fail to compile would require the person making the change to
perform some non-trivial analysis of why that hook was not declared,
then move its declaration out of the #ifdef.  It would also increase
the number of #ifdef's, which I think is both uglier and farther from
the goal of supporting several window-systems in the same session.

> P.S. I noticed that the only caller of buffer_flipping_unblocked_hook is
> unblock_buffer_flips in xdisp.c. Should this code be #ifdef'd out to
> only platforms that do this buffer flipping (HAVE_X_WINDOWS, I believe)?
> I'm not sure how much of a performance impact this code has on
> redisplay, but it introduces a record_unwind_protect in
> redisplay_preserve_echo_area.

Again, I wouldn't like to increase the number of #ifdef's if that can
be avoided.  In this case, I don't think it's justified by performance

reply via email to

[Prev in Thread] Current Thread [Next in Thread]