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: [PATCH] Renaming non-X x_* identifiers Date: Sun, 14 Apr 2019 17:02:40 +0300 Message-ID: <83ftqkk7lr.fsf@gnu.org> References: <87wokp4okn.fsf@gmail.com> <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> <87d0lpvq6n.fsf_-_@gmail.com> <83r2a5keo7.fsf@gnu.org> <87pnppu4ox.fsf@gmail.com> <83muktk9xb.fsf@gnu.org> <875zrhtg2i.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="213104"; mail-complaints-to="usenet@blaine.gmane.org" Cc: alan@idiocy.org, emacs-devel@gnu.org To: Alex Gramiak Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 14 16:03:10 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 1hFfiw-000tK3-4s for ged-emacs-devel@m.gmane.org; Sun, 14 Apr 2019 16:03:10 +0200 Original-Received: from localhost ([127.0.0.1]:36102 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFfiv-0006D6-7k for ged-emacs-devel@m.gmane.org; Sun, 14 Apr 2019 10:03:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFfip-0006Cv-8g for emacs-devel@gnu.org; Sun, 14 Apr 2019 10:03:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hFfih-0004Pu-7N; Sun, 14 Apr 2019 10:02:55 -0400 Original-Received: from [176.228.60.248] (port=3865 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hFfid-0001Iz-TH; Sun, 14 Apr 2019 10:02:54 -0400 In-reply-to: <875zrhtg2i.fsf@gmail.com> (message from Alex Gramiak on Sat, 13 Apr 2019 21:35: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:235436 Archived-At: > From: Alex Gramiak > Cc: emacs-devel@gnu.org, alan@idiocy.org > Date: Sat, 13 Apr 2019 21:35:01 -0600 > > > If every window-system is required to provide these hooks, then I > > think it will be enough to test only those which also have > > implementations on TTY frames. > > Okay. How about wrapping the required hooks in termhooks.h in #ifdef > HAVE_WINDOW_SYSTEM so that terminal-only builds that erroneously have > these hooks in their scope issue a compiler error? I generally dislike system-dependent definitions and declarations. I prefer them to be available on all systems, with some default values instead. And terminal-only builds are extremely rare (I think only Hydra does them regularly, because all the bugs in that area are flagged by Hydra), so this defense is quite weak, IME. So I think a test for the relevant hooks to be non-NULL would be a better alternative. We can document in the struct definition which members can be NULL and in what situations. > > 1) leave those symbols alone > > 2) declare them obsolete, but meanwhile put both the new and the old > > symbols into frame-parameters > > > > The above assumes that if a Lisp program does something with one of > > these parameters, that will have no effect, i.e. that these parameters > > are one-way communications from the Emacs internals to Lisp, as far as > > Lisp programs are concerned. If the communications are two-way, then > > I don't see how we can change these names; do you have any ideas? > > AFAIU it's technically possible that someone could use `put' to set a > new value, but that's tantamount to changing the internal definition of > the frame parameter setter to another frame parameter setter, so I don't > think such a use case should really be considered. > > I don't have any other ideas, but 2) doesn't sound terrible as long as > it would be removed some day. Though I don't feel strongly about the > symbols here. On second thought, I think we should simply leave these alone. They are just symbol names, and mostly used internally, so the problem is purely aesthetic and usually hidden from the view. Doing something like 2) above would be an overkill for such minor issue. > The declarations are to make the names visible to *term.c. *menu.c > contains the actual definitions, so *term.c needs declarations to set > the hook. It's why *_menu_show are there as well, even though they are > terminal hooks. Got it, thanks.