unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>, 3035@emacsbugs.donarmstrong.com
Subject: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc.
Date: Sat, 18 Apr 2009 10:16:12 +0300	[thread overview]
Message-ID: <83tz4mig8z.fsf@gnu.org> (raw)
In-Reply-To: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com>

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 17 Apr 2009 09:46:36 -0700
> Cc: 
> 
> 1. `display-graphic-p' has apparently been with us since Emacs 22, but
> there is still no mention of it in the Elisp manual. Please document
> how/when it is to be used, compared, for instance with when to use
> `window-system'.

This part is resolved by now, I presume.

> 2. In the Elisp manual, I see the use of terms such as "graphical
> terminal", "graphicical display" (also "graphics display"),
> "(non-)graphics-capable display", "text terminals" (opposed to
> graphical), "graphic characters", and "graphical attributes", without
> any real explanation or definition.

From the node "Frames", near the beginning:

       There are two classes of terminals: text-only terminals and
    graphical terminals.  Text-only terminals are non-graphics-capable
    display devices, including "terminal emulators" such as xterm.  On
    text-only terminals, each frame occupies the entire terminal screen;
    although you can create additional frames and switch between them, only
    one frame can be shown at any given time.  We refer to frames on
    text-only terminals as "terminal frames".  Graphical terminals, on the
    other hand, are graphics-capable windowing systems, such as the X
    Window System.  On a graphical terminal, Emacs can display multiple
    frames simultaneously.  We refer to such frames as "window frames".

If this is not good enough, please tell what is missing.

> Does "graphic" imply mouse support? font support? fringe support?
> color support? menu support? tool-bar support, image support?
> multiple-frame support? All of these? Does non-graphics imply absence
> of all or limited support of some (e.g. frames and colors and fonts)?

The node "Display Feature Testing" includes predicates and other APIs
that will allow you to test specifically for each one of the questions
you ask above.  Exceptions:

  . Menus are supported on all kinds of displays.  If you want to ask
    about pop-up and drop-down menus, use display-popup-menus-p.

  . Tool bar can be on or off even when it is supported, so the proper
    test is to look at the value of tool-bar-mode.

  . Fringe is covered by display-graphic-p.

> And there are apparently finer distinctions (which also don't seem to
> be explained), such as "graphical terminal that supports extended
> ASCII input" (unless what is really meant is "graphical terminal,
> which supports extended ASCII input").

Maybe it's because English nuances evade me, but I don't see any
difference between these two wordings.

> And "graphic display capable of
> displaying several frames and several different fonts" (unless what is
> really meant is that all graphic displays are so capable).

The latter.  Again, see "Display Feature Testing".

> And "graphical menu bar" (is there a non-graphical one?)

Yes, there is.

> And there are undefined terms, such as "multi-monitor"

They are defined, at least as best as someone who wrote that could:

       On some "multi-monitor" setups, a single X display outputs to more
    than one monitor.

If that definition lacks something, please tell what is missing.

> (BTW, there is quite a bit of such inappropriate quoting in the
> manuals - e.g. "function keys".)

Quoting is what makeinfo produces from @dfn, a markup that introduces
new terminology.  It should be followed or preceded by an explanation;
if there is one, what's wrong with this quoting?

> Perhaps it would be good to see all of these terms explained together
> somewhere: display, terminal, monitor, screen, graphic *, frame. (I
> assume none of these are synonyms.)

They are not.  Each one should be explained in its own place, and the
more important ones, although certainly not all, are in the Glossary
node.






  reply	other threads:[~2009-04-18  7:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-17 16:46 bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc Drew Adams
2009-04-18  7:16 ` Eli Zaretskii [this message]
2009-04-18  7:52   ` Drew Adams
2009-04-18 10:47     ` Eli Zaretskii
2009-04-18 16:23       ` Drew Adams
2009-04-18 17:20         ` Eli Zaretskii
2009-04-18 17:29           ` Drew Adams
2009-04-18 20:55             ` Eli Zaretskii
2009-04-18 21:18               ` Drew Adams
2009-04-19  3:17                 ` Stefan Monnier
2009-04-19  5:01                   ` Drew Adams
2009-04-19 18:09                     ` Stefan Monnier
2009-04-19 19:33                       ` Drew Adams
2009-04-20 16:24                         ` Stefan Monnier
2011-07-11 14:29                           ` Lars Magne Ingebrigtsen
  -- strict thread matches above, loose matches on Subject: below --
2009-04-18  1:50 Chong Yidong
2009-04-18  2:03 ` Drew Adams
2009-04-18  6:26   ` Eli Zaretskii
2009-04-18  7:17     ` Drew Adams
2009-04-18 10:39       ` Eli Zaretskii
2009-04-18 16:23         ` Drew Adams
2009-04-18 13:41   ` Chong Yidong

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=83tz4mig8z.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=3035@emacsbugs.donarmstrong.com \
    --cc=drew.adams@oracle.com \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).