Re: Rendering the em dash on the terminal

[Peter Schaffter]

> Convention, Again
> =================
> > > So ultimately, I dunno.  For the most common usages, ‘——’ may be
> > > aesthetically preferable to ‘--’.  But in some less common
> > > situations, this may confuse more than enhance.  I think it’s
> > > worth hearing what others think.

Since you ask...

When I read text at the terminal, I expect to see correctly
formatted typewritten copy such as would have satisfied
Mr. Stevenson, my typing teacher in 1970.  The introduction of
Unicode characters like em-dashes, check marks, or even bullets
draws attention to those characters, distracting from the text.
Monospaced copy is not intended to reproduce typeset copy; it is
intended to convey typographic _intent_ unambiguously.  Where dashes
are concerned, the rules were/are:

  - Em-dashes are represented by two hyphens with no space either
    side--visually easy to understand.

  - En-dashes are represented by a single hyphen surrounded by
    spaces (e.g. 2 - 3 minutes).  In typeset copy, there should be
    no space around the en-dash, however in typewritten copy, the
    notion of "range" is oddly enhanced by the spaces around the
    hyphen.  Again, I find this visually easy to grasp.

  - All dashes longer than one em are represented by four hyphens.
    The expectation is that if the copy is to be typeset, the length
    of the typeset dash will be determined by the style guide being
    followed.  Whether the typeset copy uses Mr. P——— or Mr. P————,
    Mr. P---- is perfectly clear.  Ditto the use of long dashes in
    bibliographies (which probably shouldn't be in a terminal
    document?).

  - All enumerators for lists (other than letters or digits) are
    represented by a single hyphen followed by a space, q.v.  

<opinion>
Given the clarity and former prevalence of these conventions,
I can't see any reason why documents intended for the terminal
shouldn't observe them.
</opinion>

-- 
Peter Schaffter
https://www.schaffter.ca