Re: character sets as they relate to “Raw” string literals for elisp

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> The second one is because the Texinfo manual intentionally doesn't use
> UTF-8 as @documentencoding.  Whereas we do (also intentionally).

Right, thanks for confirming that.

>> What I mean is that I think it would be better if our manuals displayed
>> em dash (written as "---") as they are displayed in the texinfo manual:
>> "--" (HYPHEN-MINUS, HYPHEN-MINUS), instead of as "—" (EM DASH).  I find
>> the former way to display this character easier to read in the monospace
>> fonts that we typically use.
>
> Others disagreed at the time, and so we decided quite some time ago to
> use @documentencoding UTF-8 in all our manuals.  (It was not only
> about the dashes; UTF-8 encoding causes quite a lot of other Unicode
> characters to be output by makeinfo.)  I see no reason to reverse that
> decision (and start all those arguments all over again).

I also see no reason to reverse that decision, if the particular case of
how em dash is displayed was already considered in detail as part of
that discussion.

If that case was not considered in detail, perhaps we could discuss it
now.  I would hope that we could agree that how em dash is displayed is
not necessarily strictly connected to "@documentencoding UTF-8"; and
that it would be useful to continue using UTF-8 encoding, but also get
the "old" way of displaying em dash.

Maybe that would require us to use an existing option in texinfo, or
maybe this would need the texinfo developers to provide a new option
that could support it.