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

[Eli Zaretskii]

> 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?

> > 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?

> > 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.

> 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.

> >> 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?

I don't remember.  But maybe I'm splitting hair here, and we can use
this predicate for iconifying etc. as well.