From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Renaming non-X x_* procedures in xdisp.c (and elsewhere) Date: Fri, 12 Apr 2019 23:10:44 +0300 Message-ID: <83imvjkmrf.fsf@gnu.org> References: <87wokp4okn.fsf@gmail.com> <83ef6xpo6b.fsf@gnu.org> <0f4be9a6-6e09-f55d-9f58-2a15aef264cd@cs.ucla.edu> <837ecpplw8.fsf@gnu.org> <871s2w510a.fsf@gmail.com> <922F9B91-2E9E-45F6-BB96-66CAE5E9FB81@gnu.org> <87k1goqpnn.fsf@gmail.com> <83imw8nspc.fsf@gnu.org> <87ftrcqg5j.fsf@gmail.com> <83bm20nm62.fsf@gnu.org> <87d0men4jx.fsf@gmail.com> <83o95sisk7.fsf@gnu.org> <87mulcnui4.fsf@gmail.com> <83bm1si7lf.fsf@gnu.org> <87ef6ont03.fsf@gmail.com> <83a7hci44l.fsf@gnu.org> <87a7hcndtc.fsf@gmail.com> <831s2nhza8.fsf@gnu.org> <87h8b4tl6n.fsf@gmail.com> <83pnprkpw5.fsf@gnu.org> <87tvf3uhp2.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="204897"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Alex Gramiak Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 12 22:11:39 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hF2WR-000rCq-Cv for ged-emacs-devel@m.gmane.org; Fri, 12 Apr 2019 22:11:39 +0200 Original-Received: from localhost ([127.0.0.1]:42114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hF2WQ-0002PA-E5 for ged-emacs-devel@m.gmane.org; Fri, 12 Apr 2019 16:11:38 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hF2Vp-0002O1-79 for emacs-devel@gnu.org; Fri, 12 Apr 2019 16:11:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hF2Vp-0006PN-4j; Fri, 12 Apr 2019 16:11:01 -0400 Original-Received: from [176.228.60.248] (port=2683 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hF2Vo-0005Sx-LW; Fri, 12 Apr 2019 16:11:00 -0400 In-reply-to: <87tvf3uhp2.fsf@gmail.com> (message from Alex Gramiak on Fri, 12 Apr 2019 13:50:01 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235376 Archived-At: > From: Alex Gramiak > Cc: emacs-devel@gnu.org > 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.