`emacs -nw', `framep' returning `t', `display-graphic-p' returning `nil'

`emacs -nw', `framep' returning `t', `display-graphic-p' returning `nil'

[Drew Adams]

I guess I don't really understand "terminal mode" and the use
of Emacs with a character-only display.  (The last time I used
Emacs regularly without a graphic display was before Emacs had
any support for graphic display!)

See https://emacs.stackexchange.com/a/37371/105 and the
question it answers.

The problem exposed there is that, by default, library dired+.el
binds key `M-S-o' (aka `M-O').  Apparently, when Emacs is used
with some terminals, or in some terminal mode(s)?, that key
sequence is sent by the arrow keys.  (On MS Windows, I don't
see the problem using `emacs -nw', but I don't claim that's
the case for all users.)

(A similar problem arose for `M-S-b', `C-M-S-b', `C-M-S-r',
`C-M-S-g', `C-M-S-m', and `C-M-S-t': they might not be
handled well in some "terminal" contexts.)

To help with the problem, I did this:

1. Added a Boolean user option,
   ` diredp-bind-problematic-terminal-keys' (t by default).

2. Prevented binding the key when the display is character-only
   AND the option is nil:

(when (or (display-graphic-p)
          diredp-bind-problematic-terminal-keys)
  (define-key dired-mode-map [(meta shift ?o)]
              'diredp-chown-this-file))

That apparently solved the problem for at least some users:
setting the option to nil prevented the key binding.

I was thinking that when `display-graphic-p' is non-nil the
problem wouldn't exist.  But apparently at least one user has
the problem even though `display-graphic-p' returns non-nil.

I use `display-graphic-p' here and there in my code, and I
wonder now if it is really doing what I have thought.  (I
used `window-sytem' before `display-graphic-p' existed.)

Searching a bit more, I see that `framep' returns plain `t'
"for a termcap frame (a character-only terminal)".  And the
user with this problem (in spite of non-nil `display-graphic-p')
does indeed get `t' for `(framep (selected-frame))'.

So my next attempt will likely be to use that instead of
`display-graphic-p'.

Before I try that, can someone please point out what I'm missing?

The doc for both `framep' and `display-graphic-p' seems to say
that the former returns `t' for a " a character-only terminal",
and the latter returns `nil' for a "text-only terminal".  But in
this user's case they apparently don't agree about his "terminal".
Is there some nuance here - a difference between a "character-only"
terminal and a "text-only" terminal?

Just what are the relations between `emacs -nw', `framep'
returning `t', and `display-graphic-p' returning `nil'?

What should I be testing for here, to detect a "terminal" or
a "terminal" mode (I'm not sure just what the problematic use
case is), so that it then makes sense to check the option value?

(Yes, I could always check just the option.  Still, I'll like
to understand this a bit better.  Is there a good test to use
here, which would show that the user's session can handle such
a key, in which case there is no need to test the option?)

Re: `emacs -nw', `framep' returning `t', `display-graphic-p' returning `nil'

[Eli Zaretskii]

> Date: Sun, 17 Dec 2017 09:10:00 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> Searching a bit more, I see that `framep' returns plain `t'
> "for a termcap frame (a character-only terminal)".  And the
> user with this problem (in spite of non-nil `display-graphic-p')
> does indeed get `t' for `(framep (selected-frame))'.
> 
> So my next attempt will likely be to use that instead of
> `display-graphic-p'.
> 
> Before I try that, can someone please point out what I'm missing?
> 
> The doc for both `framep' and `display-graphic-p' seems to say
> that the former returns `t' for a " a character-only terminal",
> and the latter returns `nil' for a "text-only terminal".  But in
> this user's case they apparently don't agree about his "terminal".
> Is there some nuance here - a difference between a "character-only"
> terminal and a "text-only" terminal?

The only way I can explain how the above contradiction happens is that
those 2 functions are called for different frames.  On Unix an Emacs
session can have both text-mode and GUI frames, and in that case it is
very important to invoke each of those 2 functions with the correct
frame, especially if pop-up frames are involved.

> Just what are the relations between `emacs -nw', `framep'
> returning `t', and `display-graphic-p' returning `nil'?

"emacs -nw" doesn't directly determine the value returned by those
functions.  What matters is the type of frame which is the argument of
these functions (by default, the selected frame at the time of the
call).  "emacs -nw" starts with a single text-mode frame, but on Unix
it can create GUI frames on various X displays, and on those GUI
frames display-graphic-p will return non-nil.

> What should I be testing for here, to detect a "terminal" or
> a "terminal" mode (I'm not sure just what the problematic use
> case is), so that it then makes sense to check the option value?

As should be apparent from the above, you logic is flawed to begin
with, because a single Emacs session can have both text-mode and GUI
frames.  So I think you should examine the value of display-graphic-p
not at key-binding time, but inside diredp-chown-this-file, because
only then you know on which kind of frame will the command run.

Re: `emacs -nw', `framep' returning `t', `display-graphic-p' returning `nil'

[Achim Gratz]

Drew Adams writes:
> The problem exposed there is that, by default, library dired+.el
> binds key `M-S-o' (aka `M-O').  Apparently, when Emacs is used
> with some terminals, or in some terminal mode(s)?, that key
> sequence is sent by the arrow keys.  (On MS Windows, I don't
> see the problem using `emacs -nw', but I don't claim that's
> the case for all users.)

The windows console will use these Esc-O sequences for arrow keys when in
"application mode", otherwise it uses Esce-[ ("normal mode").  Note
that some of the function keys also use the Esc-O prefix, while on an
ANSI terminal that has multiple character sets it would switch to the
third shift layer IIRC.

> I was thinking that when `display-graphic-p' is non-nil the
> problem wouldn't exist.  But apparently at least one user has
> the problem even though `display-graphic-p' returns non-nil.

I would interpret that to mean the display is graphics capable, but the
selected frame still runs on a terminal emulation.  I think that might
happen if you connect from a terminal based emacsclient to an emacs
server that runs on a graphical display.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: `emacs -nw', `framep' returning `t', `display-graphic-p' returning `nil'

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Sun, 17 Dec 2017 19:02:31 +0100
> 
> > I was thinking that when `display-graphic-p' is non-nil the
> > problem wouldn't exist.  But apparently at least one user has
> > the problem even though `display-graphic-p' returns non-nil.
> 
> I would interpret that to mean the display is graphics capable, but the
> selected frame still runs on a terminal emulation.

No, that'd be a wrong interpretation.  display-graphic-p reports about
a frame, and accepts a frame parameter for that purpose.

> I think that might happen if you connect from a terminal based
> emacsclient to an emacs server that runs on a graphical display.

If you see that, please report it as a bug.

Re: `emacs -nw', `framep' returning `t', `display-graphic-p' returning `nil'

[Achim Gratz]

Eli Zaretskii writes:
>> I would interpret that to mean the display is graphics capable, but the
>> selected frame still runs on a terminal emulation.
>
> No, that'd be a wrong interpretation.  display-graphic-p reports about
> a frame, and accepts a frame parameter for that purpose.

But Drew has said nothing about the two frames in question being one and
the same.  Actually it is probable they aren't, since one happens when
setting up the keymap and the other when using it.

>> I think that might happen if you connect from a terminal based
>> emacsclient to an emacs server that runs on a graphical display.
>
> If you see that, please report it as a bug.

As I said (and I think you said that too) if it's not the same frame
then all bets are off since you can easily query about two different
frames, the first one running on a terminal (emulation most likely) and
the other one on a graphical system.

I agree that this particular combination of answers should never arise
from the same frame at the same time.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

RE: `emacs -nw', `framep' returning `t', `display-graphic-p' returning `nil'

[Drew Adams]

> a single Emacs session can have both text-mode and GUI
> frames.

I see.  Learn something new everyday.

I use `display-graphic-p' in many places to guard some code
that might try to use graphic-display capabilities.

Apparently some of those uses might not really be appropriate
(might not do what I was expecting).  Thanks for the info.

> So I think you should examine the value of display-graphic-p
> not at key-binding time, but inside diredp-chown-this-file, because
> only then you know on which kind of frame will the command run.

No, that would be pretty useless.  It wouldn't even make sense
to test it in a Dired mode hook (readin or whatever), as the same
Dired buffer could be shown either or both of the two types of
frame.

I'll just remove the `display-graphic-p' test and leave only
the user option as the test.