[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Standalone 'info' should recode into display's encoding
From: |
Eli Zaretskii |
Subject: |
Re: Standalone 'info' should recode into display's encoding |
Date: |
Wed, 01 Jan 2014 05:54:32 +0200 |
> Date: Wed, 1 Jan 2014 00:15:20 GMT
> From: address@hidden (Karl Berry)
> Cc: address@hidden
>
> In my experience, the problem is not specific to Info and not specific
> to quotes. If I run cat or more or ... on a UTF-8 file in a non-UTF-8
> terminal, characters are dropped and the result beyond 7-bit ASCII is
> garbled.
In this context, is pretty much specific to quotes, because those are
used a lot in any Texinfo manual, for @code, @samp, @env, @file,
@command, and whatnot, and also for quoted text. Using Unicode
characters there just because @documentencoding of utf-8 was specified
makes any manual illegible in Info, unless your terminal happens to
support Unicode characters.
> As for controlling the output of quotes by makeinfo, an option could be
> invented, but I am not inclined to change the default behavior so I'm
> not convinced it has much utility.
It was never the default behavior of @documentencoding to affect the
quotes, until Texinfo 5. The encoding and the quotes should be
controlled by separate settings/options.
> We changed it in the first place because of vociferous complaints
> about getting ASCII quotes even with @documentencoding UTF-8.
Well, you now have vociferous complaints to the contrary.
> And after all, there is some logic to using UTF-8 quotes when the
> document says it wants UTF-8. It's no different in principle than
> accented letters.
It _is_ different, because in an otherwise English manual, having
Unicode quotes makes the manual unreadable. By contrast, having just
a few words, mostly names of people, with Unicode characters is just a
minor nuisance for those whose terminal is not UTF-8.
> At any rate, the best answer, IMHO, not requiring any changes to any
> programs, is simply not to use @documentencoding UTF-8 unless one
> actually needs it, which should be never in English-language manuals.
That doesn't stand the test of time, see the history of this in the
Emacs manuals. We might as well accept the reality.