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.bugs Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Date: Tue, 02 Apr 2019 20:23:00 +0300 Message-ID: <83ef6kfhjf.fsf@gnu.org> References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="163046"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35058@debbugs.gnu.org To: Alex Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 02 19:25:15 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1hBN9u-000gF8-Vj for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Apr 2019 19:25:15 +0200 Original-Received: from localhost ([127.0.0.1]:38987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBN9t-0005uo-UO for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Apr 2019 13:25:13 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBN9h-0005rl-3q for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2019 13:25:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBN7m-0003c0-Kb for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2019 13:23:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56211) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hBN7m-0003ba-Dc for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2019 13:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hBN7m-0008Q7-8V for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2019 13:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Apr 2019 17:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155422577632341 (code B ref 35058); Tue, 02 Apr 2019 17:23:02 +0000 Original-Received: (at 35058) by debbugs.gnu.org; 2 Apr 2019 17:22:56 +0000 Original-Received: from localhost ([127.0.0.1]:41522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBN7f-0008PZ-LL for submit@debbugs.gnu.org; Tue, 02 Apr 2019 13:22:55 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35253) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBN7e-0008PM-KC for 35058@debbugs.gnu.org; Tue, 02 Apr 2019 13:22:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBN7Z-0003F8-Aw; Tue, 02 Apr 2019 13:22:49 -0400 Original-Received: from [176.228.60.248] (port=2638 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hBN7Y-0007wB-Gw; Tue, 02 Apr 2019 13:22:48 -0400 In-reply-to: <87d0m4pcca.fsf@gmail.com> (message from Alex on Tue, 02 Apr 2019 11:05:09 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:157100 Archived-At: > From: Alex > Cc: 35058@debbugs.gnu.org > Date: Tue, 02 Apr 2019 11:05:09 -0600 > > >> On non-window systems, always use the meta modifier. > >> > >> So I changed the eq call to display-graphics-p. Is it okay to follow the > >> docstring here? > > > > No, not IMO. Doc strings can change because their purpose is > > documentation that's useful to users and programmers, whereas the > > issue in hand is ease of future maintenance. > > Hmm, it seems that my terminal Emacs accepts the super modifier but not > the hyper modifier; is this a bug in Emacs? I don't know. What do you mean by "accept"? > Should I remove the window-system condition even if I can't get > terminal Emacs to recognize the hyper key? If it is very inconvenient to use hyper on text terminals, then I think we shouldn't require users to do that. > >> The definition of blink-cursor mode states: > >> > >> This command is effective only on graphical frames. On text-only > >> terminals, cursor blinking is controlled by the terminal." > > > > That's the _current_ situation. But what would preclude the xterm > > developers, say, from adding a way of controlling that? Nothing in > > particular, I'd say. > > I agree that it's possible for the behaviour to be different eventually, > but in the meantime display-graphic-p describes the current situation > and intent better than the explicit memq does. > > If text-only terminals gain the ability to control this behaviour, then > that's the time to remove the check, no? How will you know which tests to remove? If the predicate was named display-blink-cursor-p, then you'd know immediately, but if the predicate is display-graphic-p, you'd need to decide which of those to remove and which not to remove. These predicates exist to make the decision easy. > I believe so. I'd like to replace the memq with a descriptive name, but > I'm not sure what to call it; display-ascii-encoding-p to denote that > the display can not differentiate between, e.g., C-m and RET? You mean, C-m/RET on the one hand and [return] on the other, right? I think a new predicate could be beneficial, because the function keys are supported on some text terminals, for example on MS-Windows. How about display-function-keys-p? > > Not IMO, because this is again about selection with a mouse, something > > that can (and is) supported on some TTY frames. We could use the > > hypothetical display-iconifiable-p (but we should then find a better > > name, something about selecting/raising frames perhaps). > > display-multi-focus-p? But maybe that implies that it can focus on > multiple frames simultaneously. display-can-raise-frames-p or something. (But I'm not good with coming up with names.) > What about using display-multi-frame-p? Could there be some system > that allows multiple frames, but no way to select between them? Text terminals can support multiple frames, so display-multi-frame-p is not what we want here.