bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc.
Date: Sat, 18 Apr 2009 20:20:27 +0300

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <3035@emacsbugs.donarmstrong.com>
> Date: Sat, 18 Apr 2009 09:23:09 -0700
> 
> > > > > 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:...
> > > > 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).
> > 
> > But that's what your Item 2 (above) was all about: the distinction
> > between text and graphical terminals.  What else is needed?
> 
> Yes and no. Yes for these: "graphical display", "graphics display", and
> "graphics-capable display", if one understands that they are synonymous.

They are synonymous.

> Likewise, for "text terminals" and "non-graphical-capable displays".

Also synonyms.

> It's also not clear to me how "graphic characters" and "graphical attributes"
> fit in with the others. For instance, are they implied by "graphical display"?
> Does any of them alone imply "graphical display"? What does each of them mean?

"graphic characters" have nothing to do with displays or terminals.
They are named "graphic" because they match the [:graph:] regexp.

The only place I found "graphical attributes" is in the context of
face attributes.  Since faces are supported on text terminals as well,
these also don't have any direct relation to GUI vs TTY displays.

> Dunno if things like italics and bold fonts are feasible in the Info context,
> for stuff like this.

Someone needs to write code to display _foo_ in italics and *foo* in
bold in Info buffers.

> you might also consider using bold instead of quoting, for defined
> terms (another item we discussed). That is a convention often used
> in technical doc.

I don't think it's a good idea to show bold in Info when it comes out
as slanted in print.  And making this change in the printed output as
well would be unwise, IMO, as this is a very old and well-known
convention of Texinfo.
> Maybe a glossary in Elisp would be helpful too?

Probably.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]