From unknown Sat Sep 06 04:15:36 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#3035 <3035@debbugs.gnu.org> To: bug#3035 <3035@debbugs.gnu.org> Subject: Status: 23.0.92; doc, terminology for graphics, display, terminal, etc. Reply-To: bug#3035 <3035@debbugs.gnu.org> Date: Sat, 06 Sep 2025 11:15:36 +0000 retitle 3035 23.0.92; doc, terminology for graphics, display, terminal, etc. reassign 3035 emacs submitter 3035 "Drew Adams" severity 3035 minor thanks From drew.adams@oracle.com Fri Apr 17 14:31:23 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 17 Apr 2009 21:31:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3HLVDUX018864 for ; Fri, 17 Apr 2009 14:31:21 -0700 Received: from mx10.gnu.org ([199.232.76.166]:54900) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LusFv-0003Kt-Fz for emacs-pretest-bug@gnu.org; Fri, 17 Apr 2009 13:53:39 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LusFt-00006J-4B for emacs-pretest-bug@gnu.org; Fri, 17 Apr 2009 13:53:39 -0400 Received: from rcsinet13.oracle.com ([148.87.113.125]:33128 helo=rgminet13.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LusFs-000063-Ko for emacs-pretest-bug@gnu.org; Fri, 17 Apr 2009 13:53:36 -0400 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3HHreQO018259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Apr 2009 17:53:42 GMT Received: from acsmt702.oracle.com (acsmt702.oracle.com [141.146.40.80]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3HHrCSW031370 for ; Fri, 17 Apr 2009 17:53:14 GMT Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Apr 2009 09:46:35 -0700 From: "Drew Adams" To: Subject: 23.0.92; doc, terminology for graphics, display, terminal, etc. Date: Fri, 17 Apr 2009 09:46:36 -0700 Message-ID: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm/fBKdkMhcr/YSRjqv4wCcA+tMdQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt702.oracle.com [141.146.40.80] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010204.49E8C219.0225:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) This is mainly about the Elisp manual, but some of it might also apply to the Emacs manual. 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'. 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. (BTW, shouldn't that always be "graphic", not "graphical"?) 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)? 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"). 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). And "graphical menu bar" (is there a non-graphical one?), "graphical environment"... And there are undefined terms, such as "multi-monitor", that are quoted (they should not be). Quoting a term is not a substitute for explaining or defining it. (BTW, there is quite a bit of such inappropriate quoting in the manuals - e.g. "function keys".) 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.) Node Multiple Displays is a start, but it doesn't bring it all together (as it shouldn't, since it is only about multiple displays). And then please add xrefs back to that section in places where the various terms are used. Perhaps if I reread the whole manual front to back it would become clear, but this is a muddle for me, so far. My ignorance and confusion are no doubt due partly to the fact that I haven't used Emacs without graphics support for 20 years, and if I did perhaps I'd dig in an find out what gives. But I suspect that this could be better presented for everyone. Thanks. In GNU Emacs 23.0.92.1 (i386-mingw-nt5.1.2600) of 2009-03-30 on SOFT-MJASON Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4)' From cyd@stupidchicken.com Fri Apr 17 18:48:28 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 01:48:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3I1mPwU026921 for <3035@emacsbugs.donarmstrong.com>; Fri, 17 Apr 2009 18:48:27 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 24E5D57E21C; Fri, 17 Apr 2009 21:50:16 -0400 (EDT) From: Chong Yidong To: "Drew Adams" Cc: 3035@debbugs.gnu.org Subject: Re: 23.0.92; doc, terminology for graphics, display, terminal, etc. Date: Fri, 17 Apr 2009 21:50:16 -0400 Message-ID: <87ab6ewx0n.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 1. `display-graphic-p' has apparently been with us since Emacs 22, but > there is still no mention of it in the Elisp manual. See Display Feature Testing. > 2. In the Elisp manual, I see the use of terms such as "graphical > terminal" .. without any real explanation or definition. See Frames. > And "graphical menu bar" (is there a non-graphical one?) Yes. Try `emacs -q -nw'. From drew.adams@oracle.com Fri Apr 17 19:03:26 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 02:03:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3I23O8v030947 for <3035@emacsbugs.donarmstrong.com>; Fri, 17 Apr 2009 19:03:25 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3I232PN002067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Apr 2009 02:03:03 GMT Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3I23Cgf015577; Sat, 18 Apr 2009 02:03:13 GMT Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Apr 2009 19:03:11 -0700 From: "Drew Adams" To: "'Chong Yidong'" Cc: <3035@debbugs.gnu.org> References: <87ab6ewx0n.fsf@cyd.mit.edu> Subject: RE: 23.0.92; doc, terminology for graphics, display, terminal, etc. Date: Fri, 17 Apr 2009 19:03:19 -0700 Message-ID: <001601c9bfc9$d927dd90$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ab6ewx0n.fsf@cyd.mit.edu> Thread-Index: Acm/x8mxdwMsDOG1RNemakDMI72mHQAAezxQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt707.oracle.com [141.146.40.85] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.49E934E3.00E5:SCFMA4539814,ss=1,fgs=0 Your reply hardly replies to all that is in the bug report. From eliz@gnu.org Fri Apr 17 23:26:10 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 06:26:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout2.012.net.il (mtaout2.012.net.il [84.95.2.4]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3I6Q6X9007572 for <3035@emacsbugs.donarmstrong.com>; Fri, 17 Apr 2009 23:26:08 -0700 Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KIA008009RKCW00@i_mtaout2.012.net.il> for 3035@emacsbugs.donarmstrong.com; Sat, 18 Apr 2009 09:26:00 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.124.144.191]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KIA002779VBEPB0@i_mtaout2.012.net.il>; Sat, 18 Apr 2009 09:26:00 +0300 (IDT) Date: Sat, 18 Apr 2009 09:26:01 +0300 From: Eli Zaretskii Subject: Re: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. In-reply-to: <001601c9bfc9$d927dd90$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams , 3035@debbugs.gnu.org Cc: cyd@stupidchicken.com Reply-to: Eli Zaretskii Message-id: <833ac6jx52.fsf@gnu.org> References: <87ab6ewx0n.fsf@cyd.mit.edu> <001601c9bfc9$d927dd90$0200a8c0@us.oracle.com> > From: "Drew Adams" > Date: Fri, 17 Apr 2009 19:03:19 -0700 > Cc: 3035@emacsbugs.donarmstrong.com > > Your reply hardly replies to all that is in the bug report. Which is why the bug isn't closed yet. Really, Drew, you need to learn not to be so hard on people who are trying to give serious attention to your report. If you think your attitude helps boost motivation, think again. From eliz@gnu.org Sat Apr 18 00:16:22 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 07:16:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout5.012.net.il (mtaout5.012.net.il [84.95.2.13]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3I7GIKS021808 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 00:16:19 -0700 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KIA00500C4BKW00@i_mtaout5.012.net.il> for 3035@emacsbugs.donarmstrong.com; Sat, 18 Apr 2009 10:16:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.124.144.191]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KIA002ZSC6YL900@i_mtaout5.012.net.il>; Sat, 18 Apr 2009 10:16:11 +0300 (IDT) Date: Sat, 18 Apr 2009 10:16:12 +0300 From: Eli Zaretskii Subject: Re: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. In-reply-to: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams , 3035@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: <83tz4mig8z.fsf@gnu.org> References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> > From: "Drew Adams" > 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. From drew.adams@oracle.com Sat Apr 18 00:17:08 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 07:17:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3I7H5VG021835 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 00:17:06 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3I7H57W025856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Apr 2009 07:17:07 GMT Received: from acsmt706.oracle.com (acsmt706.oracle.com [141.146.40.84]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3I7GtoV022850; Sat, 18 Apr 2009 07:16:56 GMT Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 18 Apr 2009 00:16:55 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" , <3035@debbugs.gnu.org> Cc: References: <87ab6ewx0n.fsf@cyd.mit.edu> <001601c9bfc9$d927dd90$0200a8c0@us.oracle.com> <833ac6jx52.fsf@gnu.org> Subject: RE: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. Date: Sat, 18 Apr 2009 00:17:04 -0700 Message-ID: <001f01c9bff5$ad4d3220$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <833ac6jx52.fsf@gnu.org> Thread-Index: Acm/7pFxd1lporDvT+imvowavVXUOAAAXgUg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt706.oracle.com [141.146.40.84] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.49E97E68.01B6:SCFMA4539814,ss=1,fgs=0 > > Your reply hardly replies to all that is in the bug report. > Which is why the bug isn't closed yet. I understand that. > Really, Drew, you need to learn not to be so hard on people who are > trying to give serious attention to your report. If you think your > attitude helps boost motivation, think again. Giving attention to a bug report is not somehow doing a favor for the person who reported the bug. Reporting a bug and fixing a bug are similarly (if not equally) contributions to all Emacs users. I'm not asking for a favor; I'm reporting a context in which one user found the doc confusing or wanting. HTH. If that feedback helps, fine; if not, move on. Really Eli, you need to stop telling others what they need to do. ;-) In particular with regard to presumed attitudes, intentions, and motivations. Tell your dog or your 2-year old what he needs to do, if you really have a need to preach. Spare the rest of us your presumptuous sermons. Do you have something to contribute to the bug thread? I'll bet you might, as you often make improvements to the doc. But if not... From drew.adams@oracle.com Sat Apr 18 00:52:25 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 07:52:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3I7qJO7031318 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 00:52:21 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3I7rYml015051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Apr 2009 07:53:35 GMT Received: from acsmt700.oracle.com (acsmt700.oracle.com [141.146.40.70]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3I7uLOl017819; Sat, 18 Apr 2009 07:56:22 GMT Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 18 Apr 2009 00:51:59 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" , <3035@debbugs.gnu.org> References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> <83tz4mig8z.fsf@gnu.org> Subject: RE: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. Date: Sat, 18 Apr 2009 00:52:08 -0700 Message-ID: <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83tz4mig8z.fsf@gnu.org> Thread-Index: Acm/9b3ctxueSp4cQ+S0DZJgUh1ODwAAMxTQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010201.49E986AD.0053:SCFMA922111,ss=1,fgs=0 > > 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?) From eliz@gnu.org Sat Apr 18 03:40:05 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 10:40:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout5.012.net.il (mtaout5.012.net.il [84.95.2.13]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3IAe0ru013754 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 03:40:02 -0700 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KIA00B00L32PD00@i_mtaout5.012.net.il> for 3035@emacsbugs.donarmstrong.com; Sat, 18 Apr 2009 13:39:18 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.124.144.191]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KIA002DELLIL9H0@i_mtaout5.012.net.il>; Sat, 18 Apr 2009 13:39:18 +0300 (IDT) Date: Sat, 18 Apr 2009 13:39:20 +0300 From: Eli Zaretskii Subject: Re: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. In-reply-to: <001f01c9bff5$ad4d3220$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Cc: 3035@debbugs.gnu.org, cyd@stupidchicken.com Reply-to: Eli Zaretskii Message-id: <83ocuui6uf.fsf@gnu.org> References: <87ab6ewx0n.fsf@cyd.mit.edu> <001601c9bfc9$d927dd90$0200a8c0@us.oracle.com> <833ac6jx52.fsf@gnu.org> <001f01c9bff5$ad4d3220$0200a8c0@us.oracle.com> > From: "Drew Adams" > Cc: > Date: Sat, 18 Apr 2009 00:17:04 -0700 > > Do you have something to contribute to the bug thread? I'll bet you might, as > you often make improvements to the doc. But if not... Ha! I guess by now you know better. From eliz@gnu.org Sat Apr 18 03:47:49 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 10:47:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout5.012.net.il (mtaout5.012.net.il [84.95.2.13]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3IAlkwC016383 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 03:47:48 -0700 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KIA00J00LMR6N00@i_mtaout5.012.net.il> for 3035@emacsbugs.donarmstrong.com; Sat, 18 Apr 2009 13:47:20 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.124.144.191]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KIA002W4LYUL9H0@i_mtaout5.012.net.il>; Sat, 18 Apr 2009 13:47:19 +0300 (IDT) Date: Sat, 18 Apr 2009 13:47:19 +0300 From: Eli Zaretskii Subject: Re: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. In-reply-to: <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Cc: 3035@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: <83myaei6h4.fsf@gnu.org> References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> <83tz4mig8z.fsf@gnu.org> <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> > From: "Drew Adams" > Date: Sat, 18 Apr 2009 00:52:08 -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: > > > > 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). But that's what your Item 2 (above) was all about: the distinction between text and graphical terminals. What else is needed? > (BTW, in my version, it says "On these "multi-monitor" setups, a single DISPLAY > value controls the output to all the physical monitors.") My citation was from today's CVS. > BTW, I see in passing this, in node Multiple Displays: "_the_ selected frame". > Is it normal that those underscores are shown as such? That's how emphasis is shown in Info. In print, it comes out in slanted typeface. > > 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. Sorry, I mean the Glossary in the Emacs manual, not in ELisp. From cyd@stupidchicken.com Sat Apr 18 06:39:35 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 13:39:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3IDdWJC000942 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 06:39:33 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id E73A757E24B; Sat, 18 Apr 2009 09:41:22 -0400 (EDT) From: Chong Yidong To: "Drew Adams" Cc: <3035@debbugs.gnu.org> Subject: Re: 23.0.92; doc, terminology for graphics, display, terminal, etc. References: <87ab6ewx0n.fsf@cyd.mit.edu> <001601c9bfc9$d927dd90$0200a8c0@us.oracle.com> Date: Sat, 18 Apr 2009 09:41:22 -0400 In-Reply-To: <001601c9bfc9$d927dd90$0200a8c0@us.oracle.com> (Drew Adams's message of "Fri, 17 Apr 2009 19:03:19 -0700") Message-ID: <87myaexenx.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Drew Adams" writes: > Your reply hardly replies to all that is in the bug report. Obviously. From drew.adams@oracle.com Sat Apr 18 09:24:58 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 16:24:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.9 required=4.0 tests=FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3IGOtEg016736 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 09:24:56 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3IGOq5A031877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Apr 2009 16:24:53 GMT Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3IGMw8E006636; Sat, 18 Apr 2009 16:22:59 GMT Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 18 Apr 2009 09:22:58 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" Cc: <3035@debbugs.gnu.org> References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> <83tz4mig8z.fsf@gnu.org> <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> <83myaei6h4.fsf@gnu.org> Subject: RE: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. Date: Sat, 18 Apr 2009 09:23:09 -0700 Message-ID: <003301c9c041$f6ff1810$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83myaei6h4.fsf@gnu.org> Thread-Index: AcnAE130KRztB2pPRi+bWU+XTty/sgAKwdFw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt704.oracle.com [141.146.40.82] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.49E9FE63.026B:SCFMA4539814,ss=1,fgs=0 > > > > 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. Likewise, for "text terminals" and "non-graphical-capable displays". But that was part of the point of #2: are they all different, or do some of them mean the same thing? What do the various terms mean? 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? Then there's the question of "graphic" vs "graphical". If the same thing is always meant, then it's better to be consistent and use a single term throughout. This is minor, but not necessarily only cosmetic; users can actually get confused and wonder whether such things are different. > > BTW, I see in passing this, in node Multiple Displays: > "_the_ selected frame". > > Is it normal that those underscores are shown as such? > > That's how emphasis is shown in Info. In print, it comes out in > slanted typeface. OK, I figured it might be something like that. But I wonder if that's a good idea. In technical doc, names are often considered literally (not in this case, however) - someone might think that the underscore character was, well, an underscore character. In *Help* we now use italics instead of all uppercase. Dunno if that would be possible or a good idea, but italics is often used for emphasis. Another possibility would be all uppercase (but then there is the same potential problem of being taken literally as for underscore). Dunno if things like italics and bold fonts are feasible in the Info context, for stuff like this. If so, 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. FWIW, in my own code, I use a different face for quotations (likewise, for `...'), and it is quite helpful in making them stand out. If glossary terms were bold or some other face, instead of quoted, I think it would be an improvement. Again, dunno how feasible that is. For emphasis, I'd suggest that if it's not possible to use something like italics, then nothing should be used. Emphasis should always be extra anyway; the text itself should stress what needs to be stressed. IOW, my suggestion would be to just drop the underscores, if italics (or some other face) is not possible here. > > > 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. > > Sorry, I mean the Glossary in the Emacs manual, not in ELisp. OK. Maybe a glossary in Elisp would be helpful too? My other comments might also help: mention in `?' and `C-h m' (adding "when present" or something); add as an index item; add a `G' binding. In particular, it would help to add `glossary' as an index item whenever there is a glossary. I can tell from help-gnu-emacs questions any users don't yet think in terms of `g' and node names. From drew.adams@oracle.com Sat Apr 18 09:25:33 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 16:25:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3IGPUGA017927 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 09:25:31 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3IGOiTC008110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Apr 2009 16:24:50 GMT Received: from acsmt701.oracle.com (acsmt701.oracle.com [141.146.40.71]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3IGNfb1007079; Sat, 18 Apr 2009 16:23:43 GMT Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 18 Apr 2009 09:23:41 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" Cc: <3035@debbugs.gnu.org>, References: <87ab6ewx0n.fsf@cyd.mit.edu> <001601c9bfc9$d927dd90$0200a8c0@us.oracle.com> <833ac6jx52.fsf@gnu.org> <001f01c9bff5$ad4d3220$0200a8c0@us.oracle.com> <83ocuui6uf.fsf@gnu.org> Subject: RE: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. Date: Sat, 18 Apr 2009 09:23:52 -0700 Message-ID: <003401c9c042$10d26c10$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83ocuui6uf.fsf@gnu.org> Thread-Index: AcnAEjBb419aVEDPQ/uZOTgP9ZhMwwAL4gpw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt701.oracle.com [141.146.40.71] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.49E9FE8F.0094:SCFMA4539814,ss=1,fgs=0 > > Do you have something to contribute to the bug thread? > > I'll bet you might, as you often make improvements to the doc. > > But if not... > > Ha! I guess by now you know better. The quote shows clearly that I was betting on you all along. And your contribution and help _are_ appreciated. From eliz@gnu.org Sat Apr 18 10:20:39 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 17:20:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout5.012.net.il (mtaout5.012.net.il [84.95.2.13]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3IHKZ7a001583 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 10:20:37 -0700 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KIB009003Z1PL00@i_mtaout5.012.net.il> for 3035@emacsbugs.donarmstrong.com; Sat, 18 Apr 2009 20:20:29 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.124.144.191]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KIB00FAD460RZD0@i_mtaout5.012.net.il>; Sat, 18 Apr 2009 20:20:25 +0300 (IDT) Date: Sat, 18 Apr 2009 20:20:27 +0300 From: Eli Zaretskii Subject: Re: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. In-reply-to: <003301c9c041$f6ff1810$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Cc: 3035@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: <83fxg5j2uc.fsf@gnu.org> References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> <83tz4mig8z.fsf@gnu.org> <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> <83myaei6h4.fsf@gnu.org> <003301c9c041$f6ff1810$0200a8c0@us.oracle.com> > From: "Drew Adams" > 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. From drew.adams@oracle.com Sat Apr 18 10:29:30 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 17:29:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3IHTRA1003276 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 10:29:29 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3IHSlsM015437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Apr 2009 17:28:49 GMT Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3IHTIAf026139; Sat, 18 Apr 2009 17:29:19 GMT Received: from dradamslap1 (/141.144.72.229) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 18 Apr 2009 10:29:18 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" Cc: <3035@debbugs.gnu.org> References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> <83tz4mig8z.fsf@gnu.org> <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> <83myaei6h4.fsf@gnu.org> <003301c9c041$f6ff1810$0200a8c0@us.oracle.com> <83fxg5j2uc.fsf@gnu.org> Subject: RE: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. Date: Sat, 18 Apr 2009 10:29:31 -0700 Message-ID: <000001c9c04b$3c46c180$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83fxg5j2uc.fsf@gnu.org> Thread-Index: AcnASisZbPxjQ2TXR7Oiswx2w1vPMgAACZDQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt707.oracle.com [141.146.40.85] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.49EA0DF0.0032:SCFMA4539814,ss=1,fgs=0 > > > > > > 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. OK, so the point for the doc is that these things could perhaps be mentioned. I appreciate knowing these things, but others might have the same questions or be similarly confused. Alternatively this possible confusion could perhaps be avoided, by using the same term throughout (e.g. always "text terminal", not "non-graphical-capable display"). > > 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. I see. But you said the same thing about emphasis (_foo_). If both "some quotation" and _something emphasized_ appear as slanted text in print, then how does a reader distinguish these uses? > > Maybe a glossary in Elisp would be helpful too? > > Probably. From eliz@gnu.org Sat Apr 18 13:55:14 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 20:55:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout6.012.net.il (mtaout6.012.net.il [84.95.2.16]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3IKt9aD028642 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 13:55:11 -0700 Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KIB00K00DSC2J00@i-mtaout6.012.net.il> for 3035@emacsbugs.donarmstrong.com; Sat, 18 Apr 2009 23:55:03 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.124.144.191]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KIB007FTE3P3670@i-mtaout6.012.net.il>; Sat, 18 Apr 2009 23:55:02 +0300 (IDT) Date: Sat, 18 Apr 2009 23:55:04 +0300 From: Eli Zaretskii Subject: Re: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. In-reply-to: <000001c9c04b$3c46c180$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Cc: 3035@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: <83eivpiswn.fsf@gnu.org> References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> <83tz4mig8z.fsf@gnu.org> <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> <83myaei6h4.fsf@gnu.org> <003301c9c041$f6ff1810$0200a8c0@us.oracle.com> <83fxg5j2uc.fsf@gnu.org> <000001c9c04b$3c46c180$0200a8c0@us.oracle.com> > From: "Drew Adams" > Cc: <3035@emacsbugs.donarmstrong.com> > Date: Sat, 18 Apr 2009 10:29:31 -0700 > > > 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. > > I see. But you said the same thing about emphasis (_foo_). If both "some > quotation" and _something emphasized_ appear as slanted text in print, then how > does a reader distinguish these uses? I think the reader cannot distinguish, indeed, by the typeface alone. But @emph is really very rarely used, unlike @dfn; and then, there's context. So in practice the problem is not very big one, I think. At least I myself never had problems. From drew.adams@oracle.com Sat Apr 18 14:18:03 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 18 Apr 2009 21:18:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3ILI0E1003562 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 14:18:01 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3ILHJPf002832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Apr 2009 21:17:20 GMT Received: from acsmt700.oracle.com (acsmt700.oracle.com [141.146.40.70]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3ILHo1M032155; Sat, 18 Apr 2009 21:17:51 GMT Received: from dradamslap1 (/141.144.72.229) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 18 Apr 2009 14:17:49 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" Cc: <3035@debbugs.gnu.org> References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> <83tz4mig8z.fsf@gnu.org> <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> <83myaei6h4.fsf@gnu.org> <003301c9c041$f6ff1810$0200a8c0@us.oracle.com> <83fxg5j2uc.fsf@gnu.org> <000001c9c04b$3c46c180$0200a8c0@us.oracle.com> <83eivpiswn.fsf@gnu.org> Subject: RE: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. Date: Sat, 18 Apr 2009 14:18:04 -0700 Message-ID: <000201c9c06b$2a134770$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83eivpiswn.fsf@gnu.org> Thread-Index: AcnAaAUDJ/DJiAQiT/yotIPgWzyZsgAAC9lw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt700.oracle.com [141.146.40.70] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010203.49EA437F.0123:SCFMA4539814,ss=1,fgs=0 > > > 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. > > > > I see. But you said the same thing about emphasis (_foo_). > > If both "some quotation" and _something emphasized_ appear > > as slanted text in print, then how > > does a reader distinguish these uses? > > I think the reader cannot distinguish, indeed, by the typeface alone. > But @emph is really very rarely used, unlike @dfn; and then, there's > context. So in practice the problem is not very big one, I think. At > least I myself never had problems. OK. IMO, using slant for a defined term in print is not too good, and having the same appearance for defined terms and emphasized text (unrelated) is also not too good. I'm a bit surprised, frankly, given the fine-grained print representation of things like keys - by contrast, this seems rather coarse. But if this is the long-established Texinfo convention, so be it. Here are some possibilities for defined terms in Info - that is, terms that are defined in place (whether or not they are also listed in a separate glossary). I assume that both "..." and _..._ will continue to be slant in print. And I assume emphasis in Info will continue to be shown using italics. * italics * bold * underlining (not underscore wrappers) * some other face (e.g. color) From monnier@iro.umontreal.ca Sat Apr 18 20:17:47 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 19 Apr 2009 03:17:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3J3Hike007447 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 20:17:45 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FANE06klLd+yz/2dsb2JhbACBTssag30GhSg X-IronPort-AV: E=Sophos;i="4.40,211,1238990400"; d="scan'208";a="37271810" Received: from 75-119-236-179.dsl.teksavvy.com (HELO ceviche.home) ([75.119.236.179]) by ironport2-out.teksavvy.com with ESMTP; 18 Apr 2009 23:17:39 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 06C6DB408F; Sat, 18 Apr 2009 23:17:38 -0400 (EDT) From: Stefan Monnier To: Drew Adams Cc: 3035@debbugs.gnu.org, "'Eli Zaretskii'" Subject: Re: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. Message-ID: References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> <83tz4mig8z.fsf@gnu.org> <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> <83myaei6h4.fsf@gnu.org> <003301c9c041$f6ff1810$0200a8c0@us.oracle.com> <83fxg5j2uc.fsf@gnu.org> <000001c9c04b$3c46c180$0200a8c0@us.oracle.com> <83eivpiswn.fsf@gnu.org> <000201c9c06b$2a134770$0200a8c0@us.oracle.com> Date: Sat, 18 Apr 2009 23:17:38 -0400 In-Reply-To: <000201c9c06b$2a134770$0200a8c0@us.oracle.com> (Drew Adams's message of "Sat, 18 Apr 2009 14:18:04 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > IMO, using slant for a defined term in print is not too good, and having the > same appearance for defined terms and emphasized text (unrelated) is also not > too good. AFAIK, it's just common practice for definitions. The italics is used to emphasize the fact that this term is used with a specific meaning, which is being explained. Stefan From drew.adams@oracle.com Sat Apr 18 22:01:15 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 19 Apr 2009 05:01:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3J51DBD003633 for <3035@emacsbugs.donarmstrong.com>; Sat, 18 Apr 2009 22:01:14 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3J54cZY025323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Apr 2009 05:04:39 GMT Received: from acsmt703.oracle.com (acsmt703.oracle.com [141.146.40.81]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3J511vA009533; Sun, 19 Apr 2009 05:01:05 GMT Received: from dradamslap1 (/141.144.72.229) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 18 Apr 2009 22:01:01 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: <3035@debbugs.gnu.org>, "'Eli Zaretskii'" References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com><83tz4mig8z.fsf@gnu.org><002301c9bffa$93ba5040$0200a8c0@us.oracle.com><83myaei6h4.fsf@gnu.org><003301c9c041$f6ff1810$0200a8c0@us.oracle.com><83fxg5j2uc.fsf@gnu.org><000001c9c04b$3c46c180$0200a8c0@us.oracle.com><83eivpiswn.fsf@gnu.org><000201c9c06b$2a134770$0200a8c0@us.oracle.com> Subject: RE: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. Date: Sat, 18 Apr 2009 22:01:18 -0700 Message-ID: <000301c9c0ab$e081bfb0$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcnAnbLdmUbJEOfUQsyaBE8VHeC8ywADcB+g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt703.oracle.com [141.146.40.81] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010208.49EAB011.000E:SCFMA4539814,ss=1,fgs=0 > > IMO, using slant for a defined term in print is not too > > good, and having the same appearance for defined terms > > and emphasized text (unrelated) is also not too good. > > AFAIK, it's just common practice for definitions. The italics is used > to emphasize the fact that this term is used with a specific meaning, > which is being explained. Nope. Not common practice. And that reasoning (defined term is important, so use emphasis) is an invention. But you are free to invent your own conventions. ;-) From monnier@iro.umontreal.ca Sun Apr 19 11:09:46 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 19 Apr 2009 18:09:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3JI9gE2003223 for <3035@emacsbugs.donarmstrong.com>; Sun, 19 Apr 2009 11:09:43 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAGIF60lLd+yz/2dsb2JhbACBTspSg30GhSg X-IronPort-AV: E=Sophos;i="4.40,213,1238990400"; d="scan'208";a="37282748" Received: from 75-119-236-179.dsl.teksavvy.com (HELO pastel.home) ([75.119.236.179]) by ironport2-out.teksavvy.com with ESMTP; 19 Apr 2009 14:09:36 -0400 Received: by pastel.home (Postfix, from userid 20848) id BB6307EFD; Sun, 19 Apr 2009 14:09:35 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Cc: <3035@debbugs.gnu.org>, "'Eli Zaretskii'" Subject: Re: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. Message-ID: References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> <83tz4mig8z.fsf@gnu.org> <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> <83myaei6h4.fsf@gnu.org> <003301c9c041$f6ff1810$0200a8c0@us.oracle.com> <83fxg5j2uc.fsf@gnu.org> <000001c9c04b$3c46c180$0200a8c0@us.oracle.com> <83eivpiswn.fsf@gnu.org> <000201c9c06b$2a134770$0200a8c0@us.oracle.com> <000301c9c0ab$e081bfb0$0200a8c0@us.oracle.com> Date: Sun, 19 Apr 2009 14:09:35 -0400 In-Reply-To: <000301c9c0ab$e081bfb0$0200a8c0@us.oracle.com> (Drew Adams's message of "Sat, 18 Apr 2009 22:01:18 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> > IMO, using slant for a defined term in print is not too >> > good, and having the same appearance for defined terms >> > and emphasized text (unrelated) is also not too good. >> AFAIK, it's just common practice for definitions. The italics is used >> to emphasize the fact that this term is used with a specific meaning, >> which is being explained. > Nope. Not common practice. You're simply wrong. Maybe in the texts you read it's not common practice. But in the texts I read it is. > And that reasoning (defined term is important, so use > emphasis) is an invention. Not at all. A good example would be when you define what a /type/ is. Or what an /object/ is, in a programming book. If you don't emphasize correctly, the reader may end up not noticing/understanding exactly what term you're defining because that term already has meaning to the reader. Stefan From drew.adams@oracle.com Sun Apr 19 12:33:44 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 19 Apr 2009 19:33:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.8 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, MURPHY_SEX_L2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3JJXfbb027577 for <3035@emacsbugs.donarmstrong.com>; Sun, 19 Apr 2009 12:33:42 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3JJYuDa030445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Apr 2009 19:34:57 GMT Received: from acsmt706.oracle.com (acsmt706.oracle.com [141.146.40.84]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n3JJXU66028569; Sun, 19 Apr 2009 19:33:31 GMT Received: from dradamslap1 (/141.144.64.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 19 Apr 2009 12:33:29 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: <3035@debbugs.gnu.org>, "'Eli Zaretskii'" References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com><83tz4mig8z.fsf@gnu.org><002301c9bffa$93ba5040$0200a8c0@us.oracle.com><83myaei6h4.fsf@gnu.org><003301c9c041$f6ff1810$0200a8c0@us.oracle.com><83fxg5j2uc.fsf@gnu.org><000001c9c04b$3c46c180$0200a8c0@us.oracle.com><83eivpiswn.fsf@gnu.org><000201c9c06b$2a134770$0200a8c0@us.oracle.com><000301c9c0ab$e081bfb0$0200a8c0@us.oracle.com> Subject: RE: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. Date: Sun, 19 Apr 2009 12:33:48 -0700 Message-ID: <001b01c9c125$c3982a90$0200a8c0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcnBGhrRfEFeAa9URamCd4z29bVgnQABG0jg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt706.oracle.com [141.146.40.84] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.49EB7C8B.0173:SCFMA4539814,ss=1,fgs=0 > >> > IMO, using slant for a defined term in print is not too > >> > good, and having the same appearance for defined terms > >> > and emphasized text (unrelated) is also not too good. > >> > >> AFAIK, it's just common practice for definitions. The > >> italics is used to emphasize the fact that this term is > >> used with a specific meaning, which is being explained. > > > > Nope. Not common practice. > > You're simply wrong. Maybe in the texts you read it's not > common practice. But in the texts I read it is. Read more. Technical manuals, in particular, since that is the domain in question. Yes, some do adopt the same appearance (e.g. italics) for defined terms as for emphasis (stress). You might argue that there are enough that do this that it can be called _a_ common practice, but it is by no means _the_ common practice. Making it clear that a defined term is a defined term (and not just a stressed word) helps readability and understanding. If in some medium or context there is no easy way to do that (limited set of fonts, colors, etc.), then a fallback approach is to reuse some typography (e.g. italics) that also indicates something else (e.g. emphasis). If we had only italics available to font-lock, you might argue that it is great that all font-lock keywords use italics. But we have more faces available, and we use them to indicate different things. Why? Because it helps readability. > > And that reasoning (defined term is important, so use > > emphasis) is an invention. > > Not at all. A good example would be when you define what a /type/ is. > Or what an /object/ is, in a programming book. If you don't emphasize > correctly, the reader may end up not noticing/understanding > exactly what term you're defining because that term already > has meaning to the reader. Red herring. Obviously, such terms need to be made to stand out (emphasized). I stated that from the beginning. That's precisely my point: They should stand out not only from the surrounding text, but also from ordinary emphasis (stress). They should stand out specifically _as defined terms_: if possible, they should have their own typography. This is about reusing emphasis (e.g. slant), as intended for stress, to serve another purpose (definition terms). I did not propose to change this Texinfo convention; I simply said that it's not ideal. A common example of emphasis for stress is the `em' tag in HTML, which is typically rendered using italics (whereas tag `strong' is typically rendered as bold). Such emphasis is designed to indicate stress, but there is nothing stopping someone from abusing it to fill double-duty for other purposes. That doesn't mean that such abuse is a great idea. Following your logic, in Emacs Info we should _not_ render definition terms and emphasis (for stress) differently. That is, you would apparently argue to collapse _xxx_ and "xxx" into a single appearance, since that "is common practice". That would be unfortunate for Info, and it is not ideal for print either. In technical literature there are a number of other thingies that must also stand out (parameters, syntax description terms, keywords, constants...) - from both the surrounding text and from each other. Using the same appearance (e.g. italics or slant) for several of them makes reading with understanding more difficult. Different context can help disambiguate, but in the same context confusion can result. In any case, I already stated that I'm not proposing to change the Texinfo convention ("so be it"). So your intervention is off the mark. Unless you do indeed propose to remove the existing distinction in Info between defined terms ("...") and emphasized text (_..._). That would not be good. But you might retort that it is common practice... I'll stop here. From monnier@IRO.UMontreal.CA Mon Apr 20 09:24:53 2009 Received: (at 3035) by emacsbugs.donarmstrong.com; 20 Apr 2009 16:24:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from chene.dit.umontreal.ca (chene.dit.umontreal.ca [132.204.246.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3KGOnbW018576 for <3035@emacsbugs.donarmstrong.com>; Mon, 20 Apr 2009 09:24:51 -0700 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n3KGOmse004869; Mon, 20 Apr 2009 12:24:48 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id A879F8089C; Mon, 20 Apr 2009 12:24:48 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Cc: <3035@debbugs.gnu.org>, "'Eli Zaretskii'" Subject: Re: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. Message-ID: References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> <83tz4mig8z.fsf@gnu.org> <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> <83myaei6h4.fsf@gnu.org> <003301c9c041$f6ff1810$0200a8c0@us.oracle.com> <83fxg5j2uc.fsf@gnu.org> <000001c9c04b$3c46c180$0200a8c0@us.oracle.com> <83eivpiswn.fsf@gnu.org> <000201c9c06b$2a134770$0200a8c0@us.oracle.com> <000301c9c0ab$e081bfb0$0200a8c0@us.oracle.com> <001b01c9c125$c3982a90$0200a8c0@us.oracle.com> Date: Mon, 20 Apr 2009 12:24:48 -0400 In-Reply-To: <001b01c9c125$c3982a90$0200a8c0@us.oracle.com> (Drew Adams's message of "Sun, 19 Apr 2009 12:33:48 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3257=0 >> You're simply wrong. Maybe in the texts you read it's not >> common practice. But in the texts I read it is. > Read more. Technical manuals, in particular, since that is the domain in > question. > Yes, some do adopt the same appearance (e.g. italics) for defined > terms as for emphasis (stress). You might argue that there are enough > that do this that it can be called _a_ common practice, but it is by > no means _the_ common practice. What other convention have you seen? > Red herring. Obviously, such terms need to be made to stand out > (emphasized). I stated that from the beginning. Sorry, I had missed that part. I'm glad we agree. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 11 10:37:47 2011 Received: (at 3035-close) by debbugs.gnu.org; 11 Jul 2011 14:37:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QgHcI-0002Xy-QR for submit@debbugs.gnu.org; Mon, 11 Jul 2011 10:37:47 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QgHcF-0002XF-P9 for 3035-close@debbugs.gnu.org; Mon, 11 Jul 2011 10:37:44 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=quimbies.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1QgHc1-0002A1-2J; Mon, 11 Jul 2011 16:37:29 +0200 From: Lars Magne Ingebrigtsen To: Stefan Monnier Subject: Re: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc. In-Reply-To: (Stefan Monnier's message of "Mon, 20 Apr 2009 12:24:48 -0400") Date: Mon, 11 Jul 2011 16:29:11 +0200 Message-ID: References: <001201c9bf7c$14221e40$0200a8c0@us.oracle.com> <83tz4mig8z.fsf@gnu.org> <002301c9bffa$93ba5040$0200a8c0@us.oracle.com> <83myaei6h4.fsf@gnu.org> <003301c9c041$f6ff1810$0200a8c0@us.oracle.com> <83fxg5j2uc.fsf@gnu.org> <000001c9c04b$3c46c180$0200a8c0@us.oracle.com> <83eivpiswn.fsf@gnu.org> <000201c9c06b$2a134770$0200a8c0@us.oracle.com> <000301c9c0ab$e081bfb0$0200a8c0@us.oracle.com> <001b01c9c125$c3982a90$0200a8c0@us.oracle.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-Now-Playing: John Tilbury & Sebastian Lexer's _Lost Daylight_: "Terry Jennings: For Christine Jennings 1960" X-Hashcash: 1:23:110711:monnier@iro.umontreal.ca::CX7GnbAgct5oNl9W:0000000000000000000000000000000000000JUoe X-Hashcash: 1:23:110711:3035@debbugs.gnu.org::wIuxKFGmRe8HyarP:00000000000000000000000000000000000000000NDMe X-Hashcash: 1:23:110711:eliz@gnu.org::BmCrUJH460HSwg5A:00000SEZ6 X-Hashcash: 1:23:110711:drew.adams@oracle.com::LW4V8I4MSV6h+jQ8:0000000000000000000000000000000000000000mry+ MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1QgHc1-0002A1-2J X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1310999849.21472@H2Q1XftFX31C9ZiYtpiASA X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 3035-close Cc: 'Eli Zaretskii' , 3035-close@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Reading the thread here, I think most things were resolved, so I'm closing the bug report. If there were some things that weren't handled, a new report can be opened. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From unknown Sat Sep 06 04:15:36 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 09 Aug 2011 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator