how to use graphic-display-p and window-system

how to use graphic-display-p and window-system

[Drew Adams]

> From: Eli Zaretskii Sent: Tuesday, April 14, 2009 4:33 AM
> To: 2993@emacsbugs.donarmstrong.com Subject: bug#2993
> > posn-col-row uses the `line-spacing' value in terminals.  
> > According to the doc `line-spacing' only has an effect
> > in window systems.
> 
> You mean, on graphic displays. Please use `display-graphic-p' 
> rather than assuming that if `window-system' is non-nil, the 
> display is necessarily a graphic one. At least one Emacs 
> configuration violates this assumption.

I'm not familiar with `display-graphic-p'. I've been using `window-system' to
distinguish Emacs running in a console/terminal from Emacs running with a window
mgr. In particular, I want to check whether Emacs supports keys such as S-TAB.

[Excuse me if console/terminal is not the right terminology, but I'm talking
about Emacs with no fancy keys such as S-TAB and less graphic support (colors,
fonts etc.) versus Emacs with no such limitations.]

`display-graphic-p' has apparently been with us since Emacs 22, but there is no
mention of it in the Elisp manual, even in Emacs 23. There is, however, plenty
of mention of `window-system', including node Window Systems.

Could someone please summarize the differences between the two, and when to use
one or the other? Please include how each might relate to use with a console,
-daemon, etc.

And could we then document this stuff in the manual? If it is in fact already
documented somewhere, then we can try to make it more visible or easier to find.

(FYI, I filed a bug about a general lack of clarity in the doc about terms
"graphical", "display", "terminal", and so on. But the bug site seems to be
down, so I don't know the bug #.)

Re: how to use graphic-display-p and window-system

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 17 Apr 2009 10:37:45 -0700
> 
> > You mean, on graphic displays. Please use `display-graphic-p' 
> > rather than assuming that if `window-system' is non-nil, the 
> > display is necessarily a graphic one. At least one Emacs 
> > configuration violates this assumption.
> 
> I'm not familiar with `display-graphic-p'. I've been using `window-system' to
> distinguish Emacs running in a console/terminal from Emacs running with a window
> mgr.

Well, I learn something new now and then.  Sounds like today's your
turn ;-)

> In particular, I want to check whether Emacs supports keys such as S-TAB.

That's totally unrelated to window-system or the display being
graphic.  For example, on MS-Windows, S-TAB is supported even under
"-nw", where window-system and display-graphic-p are both nil.

> [Excuse me if console/terminal is not the right terminology, but I'm talking
> about Emacs with no fancy keys such as S-TAB and less graphic support (colors,
> fonts etc.) versus Emacs with no such limitations.]

Colors nowadays are also orthogonal to window-system and
display-graphic-p: for example, there's the 256-color xterm, where the
number of colors is indistinguishable from a GUI display, but
window-system is nil and so is what display-graphic-p returns.

> `display-graphic-p' has apparently been with us since Emacs 22, but there is no
> mention of it in the Elisp manual, even in Emacs 23.

??? Are you looking at a stale ELisp manual, perhaps?  I typed
"i display-graphic-p RET" and landed in a node named "Display Feature
Testing" that documents this predicate.  This documentation exists
since the day the predicate itself was added to Emacs (which, btw, was
during Emacs 21 development, not since Emacs 22).

> Could someone please summarize the differences between the two, and when to use
> one or the other?

The only situation I know of where use of window-system is justified
is when you want to distinguish between the different kinds of window
systems, like between X and MS-Windows.  In all other cases, you are
well advised to use the APIs documented in the above-mentioned node of
the ELisp manual.

As for testing whether ``fancy'' keys are supported, I don't know how
to do that in Emacs.  Maybe someone else can suggest a way.  But
window-system is certainly not the way of doing that in a portable
manner.

RE: how to use graphic-display-p and window-system

[Drew Adams]

> > In particular, I want to check whether Emacs supports keys 
> > such as S-TAB.
> 
> That's totally unrelated to window-system or the display being
> graphic.  For example, on MS-Windows, S-TAB is supported even under
> "-nw", where window-system and display-graphic-p are both nil.

So what is it related to then?

When keys are occasionally discussed/proposed for Emacs in emacs-devel, there is
often the consideration that a given key might not be supported. I thought that
the relevant criterion was console vs window-mgr support. If not, what is it -
and how to test for it?

See also below - it seems like the Emacs source code generally uses
`window-system' to test for such keys. That's my first impression, but you say
it is "totally unrelated", so I wonder.

Perhaps there are platform-specific details or exceptions, but I'm looking for a
general test that is platform-independent, even if that means it might not be
100% reliable. I'm not going to test each platform with each
console-vs-graphics-display combination or with each possible key sequence.

> > [Excuse me if console/terminal is not the right terminology,
> > but I'm talking about Emacs with no fancy keys such as S-TAB
> > and less graphic support (colors, fonts etc.) versus Emacs
> > with no such limitations.]
> 
> Colors nowadays are also orthogonal to window-system and
> display-graphic-p: for example, there's the 256-color xterm, where the
> number of colors is indistinguishable from a GUI display, but
> window-system is nil and so is what display-graphic-p returns.

I said "less"; I didn't say "no" color support. 256 colors is not the general
color support that Emacs has with a window mgr. Can you use more or less
arbitrary #RRRGRRBBB codes, or are you limited to, say, 256 colors? That's what
I mean.

Again, if neither `window-system' nor `display-graphic-p' addresses such a
distinction, then what does? Will `display-color-p' make this distinction?

> > `display-graphic-p' has apparently been with us since Emacs 
> > 22, but there is no mention of it in the Elisp manual, even in Emacs 23.
> 
> ??? Are you looking at a stale ELisp manual, perhapss I typed
> "i display-graphic-p RET" and landed in a node named "Display Feature
> Testing" that documents this predicate.  This documentation exists
> since the day the predicate itself was added to Emacs (which, btw, was
> during Emacs 21 development, not since Emacs 22).

Oops. I must have typed the wrong search string; sorry.
I probably looked for `graphic-display-p' or something.

> > Could someone please summarize the differences between the 
> > two, and when to use one or the other?
> 
> The only situation I know of where use of window-system is justified
> is when you want to distinguish between the different kinds of window
> systems, like between X and MS-Windows.  In all other cases, you are
> well advised to use the APIs documented in the above-mentioned node of
> the ELisp manual.
> 
> As for testing whether ``fancy'' keys are supported, I don't know how
> to do that in Emacs.  Maybe someone else can suggest a way.  But
> window-system is certainly not the way of doing that in a portable
> manner.

Too bad. I hope someone has a suggestion or two.

The main two tests I need are these:

1. General colors vs no colors or limited set of colors (e.g. 256).

2. General keys vs no modifiers for keys such as TAB, insert, and prior. This
means also distinguishing between, say, C-l and C-S-l.

On a related note, in Emacs releases prior to those that have `display-mouse-p',
`display-graphic-p', etc. what are the proper tests to use for such things? Is
`window-system' as good as it gets for Emacs 20/21? I see code in the Emacs
sources such as this, for instance (in multiple places):

(if (fboundp 'display-graphic-p)
    (display-graphic-p)
  window-system)

(or (and (fboundp 'display-graphic-p) ; Emacs 21
         (display-graphic-p))
    (memq window-system '(x w32 ns))) ; Emacs 20

Grepping `window-system' in the Emacs sources, it looks like "window system" is
generally contrasted to "terminal" and "tty". Which still makes me wonder if
`window-system' isn't the best test for "fancy key" support. I think (but you
will no doubt correct me) that the tty case is what I need to distinguish, to
determine handling of keys such as, say, C-S-insert. (`window-system' seems to
be what org.el, for instance, uses to test for fancy-key handling. Likewise, for
other Emacs code.)

There might of course be some out-of-date uses of `window-system' in the Emacs
23 source code. Dunno. In any case, there are plenty of tests using
`window-system' that seem to determine handling of colors and other face
qualities, character glyphs, and fonts. I didn't analyze details, so I might be
mistaken, but that's my first impression.

There is also a comment indicating that a particular use of `window-system'
needs to be fixed to use `display-graphic-p', but that this cannot be done
until:

;; color selection depends on the number of supported colors,
;; and all defface's are changed to look at number of colors
;; instead of (type graphic) etc.

There's also an occurrence of this, to test support for face regimes:
(or window-system (display-color-p))

These things make me wonder if we are perhaps still between two chairs wrt
color-support tests. On the other hand, this seems to be the test to use for
face support:
(or (fboundp 'tty-defined-colors) window-system)

Anyway, my main question is about facy key support and general color support.
Suggestions and enlightenment welcome. Thx.

Re: how to use graphic-display-p and window-system

[Stefan Monnier]

>> That's totally unrelated to window-system or the display being
>> graphic.  For example, on MS-Windows, S-TAB is supported even under
>> "-nw", where window-system and display-graphic-p are both nil.
> So what is it related to then?

Nothing.  Using C-x @ [Ssachm], you can create pretty much any
combination of key and modifiers in any frame.

So your notion of "fancy keys" is not a hard-and-fast one: it can only
be a heuristic.  If window-system is one of w32, x, ns then you can
probably assume that most key combos are easily feasible (tho it
actually still depends on the keyboard in use, etc...), if it's nil (but
running under w32), then those combos are probably still possible.
Under DOS, window-system is not nil, but I don't know how ckey combos
can be entered.  Under xterm, window-system is nil, and many/most key
combos can also be used nowadays (and you can configure xterm&emacs for
most/all of the missing ones).

The general solution is to not try to answer the question: instead, make
sure you provide a "guaranteed" binding (i.e. a binding that only uses
keys that are known to work pretty much everywhere), and once that's
done you may also provide another binding using a less standard key.

> 1. General colors vs no colors or limited set of colors (e.g. 256).

`display-color-cells'.

> 2. General keys vs no modifiers for keys such as TAB, insert, and
>    prior.  This means also distinguishing between, say, C-l and C-S-l.

Fundamentally impossible.

> On a related note, in Emacs releases prior to those that have
> `display-mouse-p', `display-graphic-p', etc. what are the proper tests
> to use for such things?

There aren't any.

> Is `window-system' as good as it gets for Emacs 20/21?

Pretty much, yes.

> There might of course be some out-of-date uses of `window-system' in
> the Emacs 23 source code.

Yes, there are many.


        Stefan

RE: how to use graphic-display-p and window-system

[Drew Adams]

> The general solution is to not try to answer the question: 
> instead, make
> sure you provide a "guaranteed" binding (i.e. a binding that only uses
> keys that are known to work pretty much everywhere),

And those are? And that is described where?

> and once that's done you may also provide another binding
> using a less standard key.

That's exactly what I'm doing. But I want to make that basic binding the
default, when the context is unlikely to not support the fancier keys.

That's why I'm looking for a general, heuristic test - likeliness, not
certainty. I'm not looking for something that is always "correct", but for a
test that lets me choose a reasonable default. Users can of course use whatever
keys they want, but a default binding that is reasonable most of the time can be
helpful.

> > 1. General colors vs no colors or limited set of colors (e.g. 256).
> 
> `display-color-cells'.
> 
> > 2. General keys vs no modifiers for keys such as TAB, insert, and
> >    prior.  This means also distinguishing between, say, C-l 
> >    and C-S-l.
> 
> Fundamentally impossible.

Are you talking about the first sentence, the second, or both?

For the first, as far as I can see, Emacs source code does this in various
places, and it seems to use `window-system' to do it. No doubt that is not 100%
accurate, but I don't need such accuracy either.

For the second, it's certainly not impossible to bind different commands to C-l
and C-S-l, if that's what you meant.

Re: how to use graphic-display-p and window-system

[Stefan Monnier]

>> and once that's done you may also provide another binding
>> using a less standard key.

> That's exactly what I'm doing. But I want to make that basic binding the
> default, when the context is unlikely to not support the fancier keys.

No, I really mean you provide both (or more) bindings at the same
time, always.


        Stefan

RE: how to use graphic-display-p and window-system

[Drew Adams]

> >> and once that's done you may also provide another binding
> >> using a less standard key.
> 
> > That's exactly what I'm doing. But I want to make that 
> > basic binding the default, when the context is unlikely
> > to not support the fancier keys.
> 
> No, I really mean you provide both (or more) bindings at the same
> time, always.

It doesn't matter, but that is not the use case I have in mind. (And I already
do that.)

My question is about determining whether it is likely that a user is in console
mode, and consequently (probably) will not be able to simply hold down, say,
C-M-S-insert, to repeat the command bound to it. If that is likely, it is also
likely that the same thing will hold for `C-S-l', `C-M-TAB', and so on. Likely,
that's all.

(This is not about how a console user can fake the use of modifiers or remap
keys a la modmap or anything else along similar lines.)

From what I gather, the answer is still that `window-system' is about as good as
it gets, for this heuristic test. And that's what Emacs itself seems to be using
for this, in several places.

Re: how to use graphic-display-p and window-system

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Nothing.  Using C-x @ [Ssachm], you can create pretty much any
> combination of key and modifiers in any frame.

A bit off-topic, but there's no way to use C-x @ for multiple modifiers,
right?  It's always annoyed me that this doesn't seem to be possible...

[In fact, wasn't there a thread a while ago on this (I think floating the
idea of some C-x @ notation for it, like "C-x @ [ ... ]" or something)?]

Thanks,

-Miles

-- 
"Don't just question authority,
Don't forget to question me."
-- Jello Biafra

Re: how to use graphic-display-p and window-system

[Stefan Monnier]

>> Nothing.  Using C-x @ [Ssachm], you can create pretty much any
>> combination of key and modifiers in any frame.

> A bit off-topic, but there's no way to use C-x @ for multiple modifiers,
> right?  It's always annoyed me that this doesn't seem to be possible...

I thought we installed a patch some times between Emacs-21 and Emacs-22
which fixed it.  but it does seem to fail, indeed.


        Stefan

RE: how to use graphic-display-p and window-system

[Drew Adams]

> >> Nothing.  Using C-x @ [Ssachm], you can create pretty much any
> >> combination of key and modifiers in any frame.
> 
> > A bit off-topic, but there's no way to use C-x @ for 
> > multiple modifiers, right?  It's always annoyed me that
> > this doesn't seem to be possible...
> 
> I thought we installed a patch some times between Emacs-21 
> and Emacs-22 which fixed it.  but it does seem to fail, indeed.

And the doc (still) says that it is impossible.

And yes, it's off-topic. I did not ask how someone can use other keys to
simulate the use of modifiers.

Re: how to use graphic-display-p and window-system

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> A bit off-topic, but there's no way to use C-x @ for multiple modifiers,
>> right?  It's always annoyed me that this doesn't seem to be possible...
>
> I thought we installed a patch some times between Emacs-21 and Emacs-22
> which fixed it.  but it does seem to fail, indeed.

So how was it supposed to work (well, in your memory at least)...?

I vaguely recall a bunch of bikeshedding about exactly which syntax to use...

-Miles

-- 
Back, n. That part of your friend which it is your privilege to contemplate in
your adversity.

Re: how to use graphic-display-p and window-system

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 17 Apr 2009 19:54:08 -0400
> 
> Under DOS, window-system is not nil, but I don't know how ckey combos
> can be entered.

As you'd do on X, actually.  However, some C-key combinations cannot
be supported due to the fundamental limitations of DOS keyboards,
although Emacs on DOS reads the keys on the lowest feasible level,
below the OS.  One such combo that cannot be supported is C-/.

Re: how to use graphic-display-p and window-system

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Fri, 17 Apr 2009 13:15:36 -0700
> 
> See also below - it seems like the Emacs source code generally uses
> `window-system' to test for such keys. That's my first impression, but you say
> it is "totally unrelated", so I wonder.

It's a coincidence.  Most window-systems support most ``fancy''
characters.  What to make of that is up to you.

> Perhaps there are platform-specific details or exceptions, but I'm looking for a
> general test that is platform-independent, even if that means it might not be
> 100% reliable. I'm not going to test each platform with each
> console-vs-graphics-display combination or with each possible key sequence.

Then perhaps you should ask about specific keys.  Your original mail
sounded like you wanted a general-purpose, 100% correct test, but now
you say you just want some plausible heuristics.  It's hard to tell
what is the answer without knowing the specifics of what is and what
isn't important for you.

> Can you use more or less arbitrary #RRRGRRBBB codes, or are you
> limited to, say, 256 colors?

Yes, you can; see tty-color-translate.  Emacs uses that automatically
when you specify colors on a TTY, and the result on an 88-color or a
256-color TTY is generally indistinguishable from what you get on X or
any other windowing system with much more colors.

> Again, if neither `window-system' nor `display-graphic-p' addresses such a
> distinction, then what does? Will `display-color-p' make this distinction?

No.  Use display-color-cells, which returns the number of colors the
frame's display can support.  Emacs in general treats any display with
88 colors or more as full-color capable, because the human eye cannot
tell the difference.

> There might of course be some out-of-date uses of `window-system' in the Emacs
> 23 source code. Dunno. In any case, there are plenty of tests using
> `window-system' that seem to determine handling of colors and other face
> qualities, character glyphs, and fonts.

They should all be switched to using the APIs documented in "Display
Feature Testing" in the ELisp manual.

> There is also a comment indicating that a particular use of `window-system'
> needs to be fixed to use `display-graphic-p', but that this cannot be done
> until:
> 
> ;; color selection depends on the number of supported colors,
> ;; and all defface's are changed to look at number of colors
> ;; instead of (type graphic) etc.

This is already done, so that code could be fixed.

> These things make me wonder if we are perhaps still between two chairs wrt
> color-support tests.

We are not between two chairs, we just didn't fix all those places
yet.