unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 3035@emacsbugs.donarmstrong.com
Subject: bug#3035: 23.0.92; doc, terminology for graphics, display, terminal, etc.
Date: Sun, 19 Apr 2009 12:33:48 -0700	[thread overview]
Message-ID: <001b01c9c125$c3982a90$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <jwvk55ga58e.fsf-monnier+emacsbugreports@gnu.org>

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








  reply	other threads:[~2009-04-19 19:33 UTC|newest]

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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

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

  git send-email \
    --in-reply-to='001b01c9c125$c3982a90$0200a8c0@us.oracle.com' \
    --to=drew.adams@oracle.com \
    --cc=3035@emacsbugs.donarmstrong.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

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