bug#3501: 23.0.94; Use Unicode in Info (?)

["Drew Adams" <drew.adams@oracle.com>]

> > Whatever is already done is not sufficient in this regard, 
> > as indicated in the original report: I don't see composed
> > characters; I see punctuation in the
> > middle of people's names. I see J/orgensen, not Jørgensen.
> 
> Nothing is ``already done'' in the current Emacs.

I was describing the current state of the pretest the bug was reported for,
nothing more. In this pretest, I see J/orgensen, and it would be better to see
Jørgensen.

> Info files, at least originally, were pure ASCII files by design,
> because Info readers could not cope with non-ASCII characters.
> If we want to display such characters as their non-ASCII equivalents,
> we need to do this in Emacs.
> 
> Personally, I don't like the idea of Emacs converting Info files for
> display.  At the very least, it destroys the formatting of the text,
> and at worst makes the text all but unreadable.  I think if it's so
> important to us to have the names in their native scripts, we should
> simply use UTF-8 in the Texinfo sources and use --enable-encoding when
> we produce the Info files.

That is the solution then. IIUYC, if the Texinfo source file for node
Acknowledgements used Unicode and --enable-encoding were used to produce the
Info file, then the effect would be as I described for the user: s?he would
perceive only the "fancy" chars.

If that's correct, then that sounds like the way to go. I certainly agree that
if things can be done from the outset in Unicode, and if that has the proper
effect in Info for the user (which is the point), then there is no reason to
start with ASCII source and somehow twiddle the display to come up with the
effect of composed chars. That's not what I had in mind at all. 

I assumed that the solution was just to use Unicode chars in the first place (in
the source files), which is what I think you're saying also.

When you asked whether I wanted the files or the Info experience to have the
fancy chars I replied the latter, since that is the _aim_. But if the former as
a means implies the latter as the end effect, then obviously that is the way to
go.