From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alex Newsgroups: gmane.emacs.bugs Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Date: Tue, 02 Apr 2019 11:57:50 -0600 Message-ID: <878swsp9wh.fsf@gmail.com> References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> <83ef6kfhjf.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="43206"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: 35058@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 02 19:58:16 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 1hBNfp-000B4G-50 for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Apr 2019 19:58:13 +0200 Original-Received: from localhost ([127.0.0.1]:48467 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBNfo-0002tp-1i for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Apr 2019 13:58:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBNff-0002rP-FI for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2019 13:58:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBNfe-00013n-1u for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2019 13:58:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56374) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hBNfd-00013b-QP for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2019 13:58:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hBNfd-0000zV-Jd for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2019 13:58:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Apr 2019 17:58:01 +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.15542278803802 (code B ref 35058); Tue, 02 Apr 2019 17:58:01 +0000 Original-Received: (at 35058) by debbugs.gnu.org; 2 Apr 2019 17:58:00 +0000 Original-Received: from localhost ([127.0.0.1]:41685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBNfb-0000zG-Vr for submit@debbugs.gnu.org; Tue, 02 Apr 2019 13:58:00 -0400 Original-Received: from mail-pf1-f196.google.com ([209.85.210.196]:43858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBNfZ-0000z3-SI for 35058@debbugs.gnu.org; Tue, 02 Apr 2019 13:57:58 -0400 Original-Received: by mail-pf1-f196.google.com with SMTP id c8so6745181pfd.10 for <35058@debbugs.gnu.org>; Tue, 02 Apr 2019 10:57:57 -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=ucBuc6TLu51EuCLFvKZw/8kQ2f0ay0NQG+SPxVUsfjo=; b=I17FE1pmeyhzfBTk13gZvGJKG6DCsEATacfyN+ReRXCFngd71a6VxQc6uk55+Il/se dYnIbFsiC+zD5OmvLg1ria8h8grKE9CKkgOriLCPG/KNvrOFgdoDTNEP6GeePYl/Gg3K SV49R4iq0/VO3cPz7ZejSrt4WTUjhdPtedSQGpcWWMSC/Xe2wUDFKXLaF/c6J5isbuEo 16lNnChjpYDqNMzDY9vz8pbQvQ0UE7PW3WyeNs+DXUqdO3xrjMGqLlfh0pjcC0fJ2/vA x2JLIatl+DIuYyUbCBIBwS5iontNjc8m+aNIr6ZST+itQp3Z6KI2T3nsIHYQdlBfGscL uRqA== 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=ucBuc6TLu51EuCLFvKZw/8kQ2f0ay0NQG+SPxVUsfjo=; b=fYcdYOXmoBr2PNCOQ2H9PbhRIXDrs0KWq5lotgYUfuPJ3HpLX35Rc+Zx7ChCC/ctXz XCNmPFCkDyzPYbov7yDHtNRgWcz4Aoyvpz0iDlvysHEas0W/fiRLow4HdS8h0C//OjyC u+ghyy7zc4gwRwJ0ZVHkl79V07Tm66aTsgyCWDZMF2fKGxirAudHAW4VpUW68dB8ocRL 983xYqdQJpp05PcVSzwaLF7TTwCKY3UTGcpZC/FmexI2TLIxyM5a1p2BY73SxqpXjhYd NTN25AmVQU8KrShUnosmTpaEzBv1SZXwulvBqNuyLxEJYuIQ8fOjqzgYptxLUyXZOzhu 4phQ== X-Gm-Message-State: APjAAAVSKelxZbeIiwRHQmqli5pKwzOYd2+alQEqlYC/8wscFuiIJntX L7TpWywHbAXk5QZ2WFEkszsshxg8 X-Google-Smtp-Source: APXvYqzegycWwxVBnJVEyPuK5G8MdOZosK+Weo653wPxv91fxfBt0Bg3thaXieNxkHxqsNxx5ix+WA== X-Received: by 2002:a63:bd52:: with SMTP id d18mr43736184pgp.52.1554227871589; Tue, 02 Apr 2019 10:57:51 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id y12sm36836230pgq.64.2019.04.02.10.57.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Apr 2019 10:57:49 -0700 (PDT) In-Reply-To: <83ef6kfhjf.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Apr 2019 20:23:00 +0300") 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:157101 Archived-At: Eli Zaretskii writes: >> 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"? I can get terminal Emacs to recognize the super modifier (it shows up in C-h l as a `s-' prefix), but not the hyper modifier (all input is treated as if it wasn't used at all). Does the hyper modifier work for you in the terminal? In my GTK Emacs both modifiers work as expected. >> 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. It wouldn't be a matter of requiring, but instead forcing the modifier back to 'meta if both in terminal Emacs and cua-rectangle-modifier-key is 'hyper. >> >> 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. In this case there is only one test to remove, which is clearly mentioned in the docstring. I suppose my point before about 3rd-party code would apply here too, so adding display-blink-cursor-p would make sense. >> 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? [return] is another example, but I believe C-m and RET can be different in graphical Emacs. In my config I do: (define-key input-decode-map "\C-m" [C-m]) This allows me to use the control modifier with m separate from both RET and [return], as `C-h c' on the return key outputs: RET (translated from ) runs the command newline However, doing the same in terminal Emacs makes the return key use my custom [C-m] prefix. This is an example of the behaviour the predicate should be covering. I'm not sure about display-function-keys-p. That would seem to imply behaviour surrounding the `Fn' key on many keyboards. I'm not good with names either, but if we can't find a good specific name, then what about a more generic name like display-full-keybindings-p or display-extra-keybindings-p where the docstring would describe the behaviour more thoroughly? >> > 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.) Not sure, perhaps display-can-change-focus-p? >> 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. If that's the case, then why is display-multi-frame-p currently an alias for display-graphic-p?