From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alex Gramiak Newsgroups: gmane.emacs.devel Subject: Re: Renaming non-X x_* procedures in xdisp.c (and elsewhere) Date: Fri, 12 Apr 2019 13:50:01 -0600 Message-ID: <87tvf3uhp2.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="114666"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 12 21:50:18 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 1hF2Bl-000TlO-UJ for ged-emacs-devel@m.gmane.org; Fri, 12 Apr 2019 21:50:18 +0200 Original-Received: from localhost ([127.0.0.1]:41901 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hF2Bk-0003he-R4 for ged-emacs-devel@m.gmane.org; Fri, 12 Apr 2019 15:50:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hF2Be-0003er-Ls for emacs-devel@gnu.org; Fri, 12 Apr 2019 15:50:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hF2Bd-0002PD-KK for emacs-devel@gnu.org; Fri, 12 Apr 2019 15:50:10 -0400 Original-Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]:33694) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hF2Bb-0002Lz-Mn; Fri, 12 Apr 2019 15:50:09 -0400 Original-Received: by mail-pf1-x432.google.com with SMTP id h5so5644992pfo.0; Fri, 12 Apr 2019 12:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Bi1P7j4zAY/dCGL3TG7rqDgUXtZB/mFWErgiPh1ww9Y=; b=JviiriN2uJlkWfbaN5m2an8Lr7yBqDN7x3vcrbkkXH5qdie1jVCFqq8ZW0ciIvXKb+ M5qWBLdpVR5O5SxSxnx0+0BGpRnjGcCcwMHnZSlcRVRa7N/NZQfKq81CnjWZtPH2jNe5 tmXyHjZI0APdazXmAKZ23sKaIqX0d+1rY6kfe4esEj6BlA481B6jmUMqHx9/ielh9kw9 VMFa9iWIggfw3Kdh8dgsEhmW2wm/7iXxixOqfP+6C1i4zpsixP7huxG3fxD8qTjgmZod na8RezIMakM/2GZatxqKYIniE9A9qg5YwERQyxyOIIv+tbx3cg39g+PLejRuG5XjSmBL CiTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Bi1P7j4zAY/dCGL3TG7rqDgUXtZB/mFWErgiPh1ww9Y=; b=KbMRbIfA3Od/YcXelJK0EiIwIAi/YBqTAC6cGrGNq61D3RhwjGyr+udX6i2rbVgwKg xM7lX2R30aHsFofpLNvT1HN2uav8tl2VsjspY8/G72r+qwgRLROOI+fEasWvaoUj+wp/ eC984qEHVbMSsLNhYWogDaOReJ1KGcWWaXyGYAg2gVXeLJHP5gpFQm2s4M2mzXHDlJjT hNEQTyTTl+W4AFFY2UFcS2kp7OqmQDTcAoBntgW6yTTHbwzLiXYRcQUDFCo1VCYOHMYH +bUsx2FIQQ5N0svLEiwgQHDhvkbpA02OEroa3AU9PrqgTdY1qNjXR6qT+3FYl0fIkaBj rnug== X-Gm-Message-State: APjAAAUU9N80vC5NNEufEL5/bwwmGd7Tpt8egHTlWZ6LC74s3qhqkg79 tvcf/OpbZrqxjEbcn3NkTxlSJbO1 X-Google-Smtp-Source: APXvYqyRzhlIX7ISqgX79wTsMfzj0fCdIndINEvVgrUPZJh4cyyDiuNqhvEwxUNY1Xu/6bGuQlyhKg== X-Received: by 2002:a62:12c8:: with SMTP id 69mr59100520pfs.184.1555098601885; Fri, 12 Apr 2019 12:50:01 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id e7sm35819244pfc.132.2019.04.12.12.50.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 12 Apr 2019 12:50:01 -0700 (PDT) In-Reply-To: <83pnprkpw5.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 12 Apr 2019 22:03:06 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::432 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:235371 Archived-At: Eli Zaretskii writes: >> From: Alex >> Cc: emacs-devel@gnu.org >> 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.