all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Alex Gramiak <agrambot@gmail.com>
Cc: alan@idiocy.org, emacs-devel@gnu.org
Subject: Re: [PATCH] Renaming non-X x_* identifiers
Date: Mon, 15 Apr 2019 17:51:52 +0300	[thread overview]
Message-ID: <83h8azianr.fsf@gnu.org> (raw)
In-Reply-To: <87y34ctrs1.fsf@gmail.com> (message from Alex Gramiak on Sun, 14 Apr 2019 11:34:22 -0600)

> From: Alex Gramiak <agrambot@gmail.com>
> Cc: emacs-devel@gnu.org,  alan@idiocy.org
> 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
issues.



  reply	other threads:[~2019-04-15 14:51 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-23 15:07 Renaming non-X x_* procedures in xdisp.c (and elsewhere) Alex
2019-03-23 15:38 ` Stefan Monnier
2019-03-23 16:10 ` Eli Zaretskii
2019-03-23 16:41   ` Paul Eggert
2019-03-23 16:59     ` Eli Zaretskii
2019-03-23 17:39       ` Alex
2019-03-23 17:54         ` Alex
2019-03-23 18:16         ` Eli Zaretskii
2019-03-23 18:55           ` Alex
2019-03-23 19:32             ` Eli Zaretskii
2019-03-24  4:14               ` Alex
2019-03-24  4:50       ` Alex
2019-03-24  5:39         ` Eli Zaretskii
2019-03-24 15:05           ` Alex
2019-03-24 16:01             ` Yuri Khan
2019-03-24 16:13               ` Eli Zaretskii
2019-03-24 17:03                 ` Eli Zaretskii
2019-03-24 16:27             ` Eli Zaretskii
2019-03-24 18:30               ` Alex
2019-03-24 18:48                 ` Eli Zaretskii
2019-03-25 19:21                   ` Alex
2019-03-30 10:07                     ` Eli Zaretskii
2019-03-30 17:26                       ` Alex
2019-03-30 17:40                         ` Eli Zaretskii
2019-03-30 17:59                           ` Alex
2019-03-30 18:55                             ` Eli Zaretskii
2019-03-30 23:27                               ` Alex
2019-03-31 14:52                                 ` Eli Zaretskii
2019-04-11 19:07                                   ` Alex
2019-04-12 19:03                                     ` Eli Zaretskii
2019-04-12 19:50                                       ` Alex Gramiak
2019-04-12 20:10                                         ` Eli Zaretskii
2019-04-13 16:26                                           ` Alex Gramiak
2019-04-13 17:20                                             ` Eli Zaretskii
2019-04-13 16:13                                   ` [PATCH] Renaming non-X x_* identifiers (was: Renaming non-X x_* procedures in xdisp.c (and elsewhere)) Alex Gramiak
2019-04-13 17:17                                     ` Eli Zaretskii
2019-04-13 18:43                                       ` [PATCH] Renaming non-X x_* identifiers Alex Gramiak
2019-04-13 19:00                                         ` Eli Zaretskii
2019-04-14  3:35                                           ` Alex Gramiak
2019-04-14 14:02                                             ` Eli Zaretskii
2019-04-14 15:57                                               ` Alex Gramiak
2019-04-14 16:10                                                 ` Eli Zaretskii
2019-04-14 17:34                                                   ` Alex Gramiak
2019-04-15 14:51                                                     ` Eli Zaretskii [this message]
2019-04-15 17:46                                                       ` Alex Gramiak
2019-04-15 18:43                                                         ` Eli Zaretskii
2019-04-16 16:24                                                           ` Alex Gramiak
2019-04-16 16:45                                                             ` Eli Zaretskii
2019-04-16 16:59                                                               ` Alex Gramiak
2019-04-16 17:04                                                                 ` Eli Zaretskii
2019-04-16 17:07                                                                   ` Alex Gramiak
2019-04-16 18:09                                                                     ` Eli Zaretskii
2019-04-24 19:40                                                                       ` Alex Gramiak
2019-04-25  5:25                                                                         ` Eli Zaretskii
2019-04-25  9:56                                                                           ` Eli Zaretskii
2019-04-25 14:50                                                                             ` Alex Gramiak
2019-04-25 15:04                                                                               ` Eli Zaretskii
2019-04-26  6:52                                                                                 ` Robert Pluim
2019-04-26  8:07                                                                                   ` Eli Zaretskii
2019-04-26 23:12                                                                                     ` Alex Gramiak
2019-04-15 22:01                                                       ` Stefan Monnier
2019-04-16  2:29                                                         ` Eli Zaretskii
2019-04-16 12:55                                                           ` Stefan Monnier
2019-04-16 14:58                                                             ` Eli Zaretskii
2019-04-14  3:47                                         ` Stefan Monnier
2019-04-27  1:53                                     ` Basil L. Contovounesios
2019-04-27  3:46                                       ` Alex Gramiak
2019-04-27 11:37                                         ` Basil L. Contovounesios

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83h8azianr.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=agrambot@gmail.com \
    --cc=alan@idiocy.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.