bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc.

[Drew Adams]

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

Yes, that helps wrt "graphical terminal" and "text terminal" (but not with the
rest).

It might help to add a cross-reference to node Frames from some of the nodes
that use the terms it defines/explains. (Judgment call, on a case-by-case
basis.)

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

Yes, got it. Thanks.

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

This helps me, but perhaps that can also be made explicit in the manual.
(Perhaps it is, but I didn't notice it.)

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

Dependent vs independent clause. If all graphical terminals support extended
ASCII input, then it should be the latter. If only some of them do, then it
should be the former.

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

In that case, use "graphic display, which is capable of displaying several
frames and several different fonts".

The part after the comma is extra, non-essential info. It is implied by "graphic
display", since all graphic displays have this property. With no comma, the
phrase restricts the class of graphic displays to only those that have the
property.

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

I think it will be OK, if the quotes are removed.

(BTW, in my version, it says "On these "multi-monitor" setups, a single DISPLAY
value controls the output to all the physical monitors.")

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

OK, if it's a convention or a tool artifact, then nothing can be done (and
cancel what I said above about removing the quotes). I didn't realize that was
the convention we use to introduce defined terms.

What's wrong is that quoting is normally for, well, quoting. ;-) No text is
being quoted here. But it's OK to use whatever convention we want, as long as
it's consistent. I didn't know about the convention we use.

BTW, I see in passing this, in node Multiple Displays: "_the_ selected frame".
Is it normal that those underscores are shown as such? 

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

I see. That's good.

How do I get to the Glossary node? I tried `g Glossary' and got no match. I
tried `C-h m' and `?' and looked for "Glossary" in the Info mode help and
summary, but didn't find it in either. I tried `i' but didn't find "glossary" in
the index. I looked for "Glossary" in the top-level menu. I searched the manual
with C-s for "lossary". What am I missing?

(BTW, maybe `G' could take you to the glossary?)