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 23:14:06 -0600 Message-ID: <87r2ajbrhd.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> <878swsp9wh.fsf@gmail.com> <838swsfdzb.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="11613"; 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 Wed Apr 03 07:15:17 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 1hBYF2-0002sT-3B for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Apr 2019 07:15:16 +0200 Original-Received: from localhost ([127.0.0.1]:49288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBYF0-0004J7-K2 for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Apr 2019 01:15:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBYEq-0004Fu-5k for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2019 01:15:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBYEo-0006d1-RX for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2019 01:15:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56722) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hBYEo-0006ct-KP for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2019 01:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hBYEo-00076t-D7 for bug-gnu-emacs@gnu.org; Wed, 03 Apr 2019 01:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Apr 2019 05:15: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.155426845927259 (code B ref 35058); Wed, 03 Apr 2019 05:15:02 +0000 Original-Received: (at 35058) by debbugs.gnu.org; 3 Apr 2019 05:14:19 +0000 Original-Received: from localhost ([127.0.0.1]:42033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBYE6-00075a-O3 for submit@debbugs.gnu.org; Wed, 03 Apr 2019 01:14:19 -0400 Original-Received: from mail-pf1-f171.google.com ([209.85.210.171]:35381) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBYE5-00075N-2G for 35058@debbugs.gnu.org; Wed, 03 Apr 2019 01:14:18 -0400 Original-Received: by mail-pf1-f171.google.com with SMTP id t21so7545340pfe.2 for <35058@debbugs.gnu.org>; Tue, 02 Apr 2019 22:14:17 -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=dU8R5Outi9IwuOwBrzqJnDctui6S4zbsQE+Ix1EaTqI=; b=fNUUAdduAue/Lzt1rld2n9h9lamq8E9q+6Wk2Wor7FfEreaTmAlbe8wqWtQUfMXrx6 CBrYpQRZjV9avD3Dj8p+IRR9diMy3XAcoMke+RCo1CYmlmAwjJ57pAhoYEK3pWAmJb/4 jy+ryMxG1C8MgP2ENAKbZ3hiDQmpAOcBZTkMZ7yT6N8qandzG/4glKTSuswGDJhoofVe H0phmTdSvBDmtimg0rWbylRU9QdAiiVWvEyi+hx4hVpHGUhWiH2grw14F4bscJjPQNyj S2CbTemfnn5SiTW7EFV0uVSIjj3dzFQOT4AuLFky2TaJoVvGnwLSZ1qaXF9jOwp2l+EW gZVA== 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=dU8R5Outi9IwuOwBrzqJnDctui6S4zbsQE+Ix1EaTqI=; b=EEyCMFHmJ3XIw9veCs/bnDJl2uP1NqJCQtQ7thUeEvaW1Rm7xfKCpyqenAvXm/xOA9 HrRTyBenJGYsHbCV8lXFK/LveG0TYFkqQoV+/6EefQqZbOhqAOf4vN0jeQvJQjG9wsic Mg0v2n7iMUF34N7VZpyJhAEfPc88IA80w8P2UR68/3PidYtk0wpdtHaF0FBqhF+tRbr+ OIinobjzdFrKFAqh/PiPks9IKPgsE4BQ3U/Njx/bXnAoolfLIx5nFrZzyYr5pdNHOuu4 SbVubYlCZTbxCM3/2D9FrR9qHJ7+tF5H/HbsJtRq25DopCajkfAHwjhdSPjSbzbiFXIK UQ1Q== X-Gm-Message-State: APjAAAVw81fOGRJYe9F8QQfNt5/0K02r0FbGkfC/dh9aUMIHatjIZa0A Swndvb0OHocXCnUUACx5MHLflof4 X-Google-Smtp-Source: APXvYqwyZRJ0UYlnfhnrKS96S7rcIScDGC041dRmSUWB4pyfHQ1P+YAxVZajJujmzXA0U7LlIOAotQ== X-Received: by 2002:aa7:8b0c:: with SMTP id f12mr72557206pfd.154.1554268450591; Tue, 02 Apr 2019 22:14:10 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id f7sm36073648pga.56.2019.04.02.22.14.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Apr 2019 22:14:09 -0700 (PDT) In-Reply-To: <838swsfdzb.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Apr 2019 21:39:52 +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:157115 Archived-At: Eli Zaretskii writes: >> From: Alex >> Cc: 35058@debbugs.gnu.org >> Date: Tue, 02 Apr 2019 11:57:50 -0600 >> >> >> 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). > > That might mean your terminal is unable to _generate_ the modifier. > What happens if you use the "C-x @ h" prefix, does it produce > hyper-modified keys? You're right, and it does work with "C-x @ h". It seems that terminals supporting either super/hyper are rare (or nonexistent -- I tried a few popular ones to no avail). My terminal only happens to support super since someone hard-coded it to output "C-x @ s" with the super modifier specifically to support Emacs. >> > 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. > > Sorry, I don't understand. Can you show how would you like to remove > the condition? I don't agree with my position in my last email since I found out that my terminal has a special workaround for 'super. Removing the condition would just mean always using cua-rectangle-modifier-key in cua--init-keymaps even if in a terminal: (setq cua--rectangle-modifier-key cua-rectangle-modifier-key) This would mean that terminal users that can't use super/hyper modifiers easily would might find it confusing, but the current behaviour is a bit confusing as is. >> > 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 think [return] the function key is a much more frequent case for the > distinction. TTY frames generally don't have function keys as > symbols, they have escape sequences which we translate to function > keys. Yeah, I'll agree that [return] is more common; I was just describing my usage of C-m (or [C-m]) here. Why do you only say that TTY frames _generally_ don't have function keys as symbols? >> I'm not sure about display-function-keys-p. That would seem to imply >> behaviour surrounding the `Fn' key on many keyboards. > > A doc string will explain what we mean. Right, but I still don't think the name is particularly great considering the common notion of function key (en.wikipedia.org/wiki/Function_key). How about display-symbol-keys-p (if TTY frames can't support symbols in key sequences)?