bug#35058: [PATCH] Use display-graphic-p in more cases

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> 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 <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'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?