[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35058: [PATCH] Use display-graphic-p in more cases
From: |
Alex |
Subject: |
bug#35058: [PATCH] Use display-graphic-p in more cases |
Date: |
Tue, 02 Apr 2019 23:14:06 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Alex <agrambot@gmail.com>
>> 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 <return>) 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)?
- bug#35058: [PATCH] Use display-graphic-p in more cases, Alex, 2019/04/01
- bug#35058: [PATCH] Use display-graphic-p in more cases, Eli Zaretskii, 2019/04/01
- bug#35058: [PATCH] Use display-graphic-p in more cases, Drew Adams, 2019/04/01
- bug#35058: [PATCH] Use display-graphic-p in more cases, Alex, 2019/04/02
- bug#35058: [PATCH] Use display-graphic-p in more cases, Eli Zaretskii, 2019/04/02
- bug#35058: [PATCH] Use display-graphic-p in more cases, Alex, 2019/04/02
- bug#35058: [PATCH] Use display-graphic-p in more cases, Eli Zaretskii, 2019/04/02
- bug#35058: [PATCH] Use display-graphic-p in more cases,
Alex <=
- bug#35058: [PATCH] Use display-graphic-p in more cases, Eli Zaretskii, 2019/04/03
- bug#35058: [PATCH] Use display-graphic-p in more cases, Alex, 2019/04/03
- bug#35058: [PATCH] Use display-graphic-p in more cases, Eli Zaretskii, 2019/04/05
- bug#35058: [PATCH] Use display-graphic-p in more cases, Alex, 2019/04/05
- bug#35058: [PATCH] Use display-graphic-p in more cases, Eli Zaretskii, 2019/04/05
- bug#35058: [PATCH] Use display-graphic-p in more cases, Alex, 2019/04/07
bug#35058: [PATCH] Use display-graphic-p in more cases, Stefan Monnier, 2019/04/07