RE: [External] : Re: character sets as they relate to “Raw” string literals for elisp

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

>> Such ugly writing style where an en dash is not separated from the
>> nearby words by whitespace makes the Info manual less readable.
>> For example, in (info "(emacs) After a Crash"):
>>
>>   ...to retrieve them from a core dump–provided that a...
>>
>> This leaves one to wonder what does this word mean:
>> "dump-provided"?
>
> Good example.
>
> Use of an en dash that way is inappropriate (irregular,
> not conventional).  An em dash _would_ be appropriate
> there, but not an en dash.

First, that just looks like a typo, there should be an em dash (—) above
as Drew says.  IOW, you need to use "---" to get the correct symbol.
See (info "(texinfo) Conventions").  (The em dash is correctly used in
other places in trouble.texi.)

    "...to retrieve them from a core dump—provided that a..."

That makes it a little bit better.

In print, an em dash will look okay without any spaces, as it will be
longer (in any serious typeface).  Having no spaces is the more
traditional style, while most newspapers, for example, put spaces around
em dash for clarity and ease of reading.

Still, if you are not a native English speaker it does take some getting
used to this style.  But it is correct; white-space is *not* needed.

That said, I agree that with monospace fonts the em dash would really
need to have some white-space on each side.  I don't know why Texinfo
doesn't insert a space for info files.  It probably should.

BTW, try this: visit "(emacs) After a Crash" and then
M-x variable-pitch-mode RET.