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

[Eli Zaretskii <eliz@gnu.org>]

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

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

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

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

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

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