Re: Display of em dashes in our documentation

[Stefan Kangas <stefankangas@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> One drawback is that em dash is only confirmed to be problematic in some
>> situations; that is when they are written "like—this" with no space in
>> between, whereas in situations "like — this" I think it is much
>> preferable to show the actual Unicode character.
>
> That's splitting hair, IMO.  The latter should never happen in a
> well-written manual.

Even if your second claim is true, your proposal, IIUC, is that this
mode could be used even outside of Info-mode.  If we introduce a mode
that fixes this in some cases, there is a risk that it will lead to
suboptimal results in others.  I do not think that pointing this out is
unimportant or "splitting hairs".

> What will that do to byte offsets in Info tag tables?  I'd rather
> avoid modifying the buffer contents.

What do you mean by "byte-offsets in Info tag tables"?  Do you mean that
this approach risks leaving a table misaligned?  If so, I think that is
correct, and clearly a drawback.  I don't see an easy way around it with
this approach (but I also don't see a scenario when you would properly
use an em dash in a table).

I agree that it would be better not to modify the buffer contents, but
IIUC that would require changes in Texinfo to support this use-case.

>> In any monospace font, I certainly prefer this:
>>
>>        When ‘recover-session’ is done, the files you’ve chosen to recover
>>     are present in Emacs buffers.  You should then save them.  Only
>>     this — saving them — updates the files themselves.
[...]
>
> But that's against our style of writing documents, isn't it?  I
> believe the usual US English style is not to leave whitespace around
> em dash.

We have discussed this up-thread, and the situation is clear: the most
common style in printed books is to not use whitespace, whereas in
papers and magazines the most common style is to use whitespace.  Both
approaches are valid and commonly used in properly written English.

AFAIK, there is no consensus about how this should be handled when you
render text in a monospace font for display on a screen.  No one has
presented any evidence that such a consensus exists.

I don't know, but I assume that the reason that Texinfo doesn't leave
space around em dash is because this is considered undesirable in
printed manuals.  But I believe treating the printed manual as exactly
analogous to the screen is a mistake here; the practical considerations
that made Texinfo render em dash as "--" in the past still apply when
using UTF-8, as long as the result is intended for display in a
mono-space font.  The better solution in that case is to render it as
" — " or "--", even when the rest of the text is UTF-8.

But with all this, I am actually beginning to wonder if this shouldn't
properly be fixed in Texinfo itself.