From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: 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> 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> Reply-To: Drew Adams , 3035@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1240170318 18230 80.91.229.12 (19 Apr 2009 19:45:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Apr 2009 19:45:18 +0000 (UTC) Cc: 3035@emacsbugs.donarmstrong.com To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 19 21:46:37 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LvcyJ-0004uE-E5 for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Apr 2009 21:46:36 +0200 Original-Received: from localhost ([127.0.0.1]:40768 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lvcwu-0007aU-Kx for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Apr 2009 15:45:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lvcvt-0006uU-38 for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2009 15:44:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lvcvl-0006qh-En for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2009 15:44:02 -0400 Original-Received: from [199.232.76.173] (port=43860 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lvcvk-0006qS-SO for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2009 15:43:56 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:53036) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lvcvj-0000cV-Eg for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2009 15:43:56 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3JJhpA1030471; Sun, 19 Apr 2009 12:43:53 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n3JJe6EK029254; Sun, 19 Apr 2009 12:40:06 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 19 Apr 2009 19:40:06 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 3035 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 3035-submit@emacsbugs.donarmstrong.com id=B3035.124016962427591 (code B ref 3035); Sun, 19 Apr 2009 19:40:06 +0000 Original-Received: (at 3035) by emacsbugs.donarmstrong.com; 19 Apr 2009 19:33:44 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-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 Original-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 Original-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 Original-Received: from dradamslap1 (/141.144.64.14) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 19 Apr 2009 12:33:29 -0700 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 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Sun, 19 Apr 2009 15:44:02 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:27357 Archived-At: > >> > 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.