all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: emacs-devel@gnu.org
Subject: `emacs -nw', `framep' returning `t', `display-graphic-p' returning `nil'
Date: Sun, 17 Dec 2017 09:10:00 -0800 (PST)	[thread overview]
Message-ID: <a508c72a-05ba-4b83-a687-5e7b4134821f@default> (raw)

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



             reply	other threads:[~2017-12-17 17:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-17 17:10 Drew Adams [this message]
2017-12-17 17:34 ` `emacs -nw', `framep' returning `t', `display-graphic-p' returning `nil' Eli Zaretskii
2017-12-17 18:02 ` Achim Gratz
2017-12-17 20:10   ` Eli Zaretskii
2017-12-17 21:06     ` Achim Gratz
     [not found] <<a508c72a-05ba-4b83-a687-5e7b4134821f@default>
     [not found] ` <<836095qmvk.fsf@gnu.org>
2017-12-17 22:26   ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a508c72a-05ba-4b83-a687-5e7b4134821f@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.