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: [RFC] Using a display_info union instead of a typedef Display_Info Date: Fri, 12 Apr 2019 22:23:12 +0300 Message-ID: <83mukvkoyn.fsf@gnu.org> References: <87mukvw4la.fsf@gmail.com> <83v9zjkt05.fsf@gnu.org> <877ebzvzgy.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="3181"; mail-complaints-to="usenet@blaine.gmane.org" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alex Gramiak Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 12 21:23:41 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 1hF1lz-0000el-5s for ged-emacs-devel@m.gmane.org; Fri, 12 Apr 2019 21:23:39 +0200 Original-Received: from localhost ([127.0.0.1]:41637 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hF1ly-0003Fy-6I for ged-emacs-devel@m.gmane.org; Fri, 12 Apr 2019 15:23:38 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hF1lp-0003Fg-Gk for emacs-devel@gnu.org; Fri, 12 Apr 2019 15:23:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hF1lp-0001nN-4X; Fri, 12 Apr 2019 15:23:29 -0400 Original-Received: from [176.228.60.248] (port=3719 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hF1lo-0004nL-KF; Fri, 12 Apr 2019 15:23:28 -0400 In-reply-to: <877ebzvzgy.fsf@gmail.com> (message from Alex Gramiak on Fri, 12 Apr 2019 12:40:45 -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:235365 Archived-At: > From: Alex Gramiak > Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca > Date: Fri, 12 Apr 2019 12:40:45 -0600 > > > Looks to me like replacing one set of window-system specific code with > > another: still the same #ifdef's and the same window-system specific > > code fragments. Maybe I'm missing something, but it doesn't look to > > me like a change for the better. > > There will always have to be window-system specific code somewhere. The > difference with this patch is that the changed parts of the code will be > able to be used by multiple different window systems. That is to say, I > believe this is a necessary step towards Stefan's goal of using multiple > window systems simultaneously. > > Note how before there was the implicit conditional compilation regarding > the definition of check_x_display_info and x_get_arg that allowed the > procedure to be used by _only_ 1 window system, but decode_display_info > and gui_display_get_arg would be able to handle _all_ graphical window > systems that Emacs is built with. > > This currently doesn't mean any functional change as that number can > currently only be 1, but it would be nice for that to change. Again, I > believe this is (part of) the way to do so. We've been through this before: if these changes don't come together with, or closely followed by, the code to support using several window-systems in the same session, I'd prefer not to make these changes at this time. The advantages you describe are at this point theoretical, whereas the disadvantage -- making the code less familiar for veteran Emacs hackers -- is very real. Let's invest our time and energy in making changes that are useful today, not in some distant future. > To show how it's used, I've included a diff that uses > decode_display_info to simplify all 3 check_x_display_info > implementations into a single conditional. (I could remove that > conditional with another terminal hook, but I'm not sure that's worth > it). There's a way to attain that without the massive changes you propose: just make a single function which dispatches by the type of output_data. We won't be able to judge which alternative is better until and unless we have real code which implements this feature. Thanks.