Re: Emacs-diffs Digest, Vol 100, Issue 28

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Eli Zaretskii]

> revno: 103590
> committer: Glenn Morris <rgm@gnu.org>
> branch nick: trunk
> timestamp: Tue 2011-03-08 00:59:18 -0800
> message:
>   Convert some names in texinfo files to UTF-8.
>   
>   * doc/emacs/Makefile.in (MAKEINFO_OPTS): Add --enable-encoding.
>   * doc/emacs/emacs.texi (Acknowledgments):
>   * doc/emacs/ack.texi (Acknowledgments): Names to UTF-8.

That kind of change should have been discussed before committing it.
It _might_ be OK to use --enable-encoding to produce the on-line Info
version of the manuals (and even then not all Info readers out there
will support UTF-8), but have you thought about the printed output?
I'm not sure texinfo.tex and TeX will support UTF-8 encoding, or any
other multibyte encoding, for that matter.

We should at least consult with Karl Berry (CC'ed) before making any
such changes.

AFAIK, we previously used non-ASCII encoding only in manuals for which
the FSF does not produce books it wants to sell.  But the Emacs and
ELisp manuals _are_ on sale from the FSF.

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Glenn Morris]

Eli Zaretskii wrote:

> That kind of change should have been discussed before committing it.

Acting on a 2 year old directive from Stefan:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3501#70

  Yes, of course, we should now use utf-8 for that Texinfo file and pass
  --enable-encoding to makeinfo.

to which no-one commented.

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Karl Berry]

What I can tell you is that texinfo.tex is currently limited to the
Computer Modern fonts and a few extras.  So most Latin-based languages
are more or less ok.  Anything using other scripts -- Cyrillic, Greek,
Indian, Chinese, Arabic, Urdu, whatever -- is not going to work.  You
might not get an error from TeX but you won't get any useful output
either.  I suggest checking the .log for "missing character" messages.

As far as makeinfo goes, all currently released versions blindly pass
the input to the output as far as such "binary" characters go.  So if
you write some Chinese UTF-8 in the input, those bytes will end up in
the output just as written.  No actual Unicode processing takes place,
as required by Hindi and Arabic, for example.

Although I am not one to downplay the importance of correctly
typesetting people's names, I question whether doing so requires using
UTF-8 for the manual.  After all, the manuals are about Emacs and are
written in US English using 7-bit ASCII, not about stressing the
typesetting system by expecting to be able to handle every script in the
world in one document simultaneously.

Here's a kludge that comes to mind as a possible workaround: Perhaps the
names could be written in a separate document that uses standard LaTeX
(or XeLaTeX), where all the necessary fonts are at least conceivably
available (though don't expect it to be zero effort to get it all to
work).  Or perhaps it takes several small documents, one for each major
script family.  The separate documents could be included in the manual
in their .pdf form for the TeX output.  

Best,
karl

Re: Typesetting non-ASCII names in Emacs manuals (was: Emacs-diffs Digest, Vol 100, Issue 28)

[Eli Zaretskii]

> Date: Tue, 8 Mar 2011 23:14:15 GMT
> From: karl@freefriends.org (Karl Berry)
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> 
> Although I am not one to downplay the importance of correctly
> typesetting people's names, I question whether doing so requires using
> UTF-8 for the manual.  After all, the manuals are about Emacs and are
> written in US English using 7-bit ASCII, not about stressing the
> typesetting system by expecting to be able to handle every script in the
> world in one document simultaneously.

Exactly my thoughts, yes.

> Here's a kludge that comes to mind as a possible workaround: Perhaps the
> names could be written in a separate document that uses standard LaTeX
> (or XeLaTeX), where all the necessary fonts are at least conceivably
> available (though don't expect it to be zero effort to get it all to
> work).  Or perhaps it takes several small documents, one for each major
> script family.  The separate documents could be included in the manual
> in their .pdf form for the TeX output.  

Thanks.  Could you perhaps outline the procedure for each of these
workarounds and perhaps show some examples, or point to some
documentation or discussions from which such a procedure could be
gleaned?

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Glenn Morris]

Karl Berry wrote:

> What I can tell you is that texinfo.tex is currently limited to the
> Computer Modern fonts and a few extras.  So most Latin-based languages
> are more or less ok. 

That's all we are talking about at the moment.

> Anything using other scripts -- Cyrillic, Greek, Indian, Chinese,
> Arabic, Urdu, whatever -- is not going to work. You might not get an
> error from TeX but you won't get any useful output either. I suggest
> checking the .log for "missing character" messages.

There aren't any such scripts in the files.

I checked the TeX .log on RHEL5 (makeinfo 4.8) - no such messages. (No
such messages on the ancient RHEL4 with makeinfo 4.7 either; but there
are a few "Font ecrm1095 at 603 not found" things there). No problems on
Debian testing either. Debian stable has texinfo 4.13 so I wouldn't
expect any problems there either.

So I don't believe the production of pdfs is a factor in whether this
particular change is worth making or not.

Re: Typesetting non-ASCII names in Emacs manuals

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Wed, 09 Mar 2011 02:57:58 -0500
> 
> Karl Berry wrote:
> 
> > What I can tell you is that texinfo.tex is currently limited to the
> > Computer Modern fonts and a few extras.  So most Latin-based languages
> > are more or less ok. 
> 
> That's all we are talking about at the moment.

But once we use UTF-8, there's no practical way of ensuring that it
stays that way.

> So I don't believe the production of pdfs is a factor in whether this
> particular change is worth making or not.

I'm not sure the FSF goes through PDF when they typeset the manuals
for sale.  Perhaps the PS output should also be checked.

Re: Typesetting non-ASCII names in Emacs manuals

[Stefan Monnier]

>> That's all we are talking about at the moment.
> But once we use UTF-8, there's no practical way of ensuring that it
> stays that way.

But utf-8 is "the right way" in the long term, and it already works now,
so there's no point coming up with a hack that also works now but that
we'll want to get rid of when Texinfo finally supports it better.


        Stefan

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Glenn Morris]

Eli Zaretskii wrote:

> I'm not sure texinfo.tex and TeX will support UTF-8 encoding, or any
> other multibyte encoding, for that matter.

PDF looks fine on RHEL5, built using makeinfo 4.8. We have a very recent
texinfo.tex in doc/misc which seems to support UTF-8, and it gets used
when running TeX on all Emacs manuals.

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org,  karl@freefriends.org (Karl Berry)
> Date: Tue, 08 Mar 2011 13:50:08 -0500
> 
> Eli Zaretskii wrote:
> 
> > I'm not sure texinfo.tex and TeX will support UTF-8 encoding, or any
> > other multibyte encoding, for that matter.
> 
> PDF looks fine on RHEL5, built using makeinfo 4.8.

??? How come makeinfo 4.8 doesn't barf on the @documentencoding line
for you, as it does for me and Juanma?  Can you produce an Info manual
with that version?

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Glenn Morris]

Eli Zaretskii wrote:

> ??? How come makeinfo 4.8 doesn't barf on the @documentencoding line
> for you, as it does for me and Juanma?  Can you produce an Info manual
> with that version?

There is indeed a gripe when running `make info':

 warning: unrecognized encoding name `UTF-8'.

but an info file is still produced and the command exits with status 0.
Since RHEL5 is rather old (it ships with Emacs 21), that doesn't bother
me.

There are no errors, warnings, or font-related complaints when running
`make emacs.pdf', and the resulting pdf looks fine.

   This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)


I can even make a pdf on the venerable RHEL4 (with makeinfo 4.7) that
superficially looks fine, though in this case there are some complaints
about fonts when building emacs.pdf.

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org,  karl@freefriends.org
> Date: Tue, 08 Mar 2011 14:19:25 -0500
> 
> Eli Zaretskii wrote:
> 
> > ??? How come makeinfo 4.8 doesn't barf on the @documentencoding line
> > for you, as it does for me and Juanma?  Can you produce an Info manual
> > with that version?
> 
> There is indeed a gripe when running `make info':
> 
>  warning: unrecognized encoding name `UTF-8'.
> 
> but an info file is still produced and the command exits with status 0.
> Since RHEL5 is rather old (it ships with Emacs 21), that doesn't bother
> me.

Well, it does bother me.  Can we please find a solution for this, and
if not, revert it?

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Glenn Morris]

Eli Zaretskii wrote:

>> Since RHEL5 is rather old (it ships with Emacs 21), that doesn't bother
>> me.
>
> Well, it does bother me.  Can we please find a solution for this, and
> if not, revert it?

A solution for what?

The latest versions of both Debian stable and RHEL, which tend to be the
GNU/Linux distributions with the oldest infrastructure, both have
texinfo 4.13.
http://cvs.savannah.gnu.org/viewvc/*checkout*/texinfo/texinfo/NEWS tells
me this supports UTF-8 in info. Older versions of makeinfo will still
work, just with a few odd characters.

I've shown there is no apparent problem with making pdfs (even with
older versions of makeinfo).

So I guess the problem is the apparent lack of a readily available
working pre-built binary of a recent version of texinfo on MS Windows. I
can't help you find a solution for that. I don't mind reverting this
because of that.

Re: Typesetting non-ASCII names in Emacs manuals

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org,  karl@freefriends.org
> Date: Wed, 09 Mar 2011 03:03:16 -0500
> 
> Eli Zaretskii wrote:
> 
> >> Since RHEL5 is rather old (it ships with Emacs 21), that doesn't bother
> >> me.
> >
> > Well, it does bother me.  Can we please find a solution for this, and
> > if not, revert it?
> 
> A solution for what?

A solution for the warning and -- more importantly -- for producing an
Info file that doesn't render correctly (because it has no coding
cookie, since makeinfo 4.8 didn't recognize the document encoding).

> The latest versions of both Debian stable and RHEL, which tend to be the
> GNU/Linux distributions with the oldest infrastructure, both have
> texinfo 4.13.
> http://cvs.savannah.gnu.org/viewvc/*checkout*/texinfo/texinfo/NEWS tells
> me this supports UTF-8 in info. Older versions of makeinfo will still
> work, just with a few odd characters.

We never required a too new version of Texinfo for producing the Emacs
manuals.  For that reason, we tend not to use latest features of the
Texinfo language.  Why start now, and over such a minor issue at that?

And if "a few odd characters" is not an issue, then why make this
change at all?  It was, after all, to fix "a few odd characters" in
the names of some contributors, wasn't it?

> So I guess the problem is the apparent lack of a readily available
> working pre-built binary of a recent version of texinfo on MS Windows.

That, and the fact that Texinfo doesn't have a Windows-friendly
configury in the distro, yes.  I sometimes build Windows ports myself,
if the available pre-built ones are broken.  But Texinfo 4.8 is not
broken by any measure, and it served me and others very well until
now.  It hardly justifies a significant effort needed to build a port
of a newer Texinfo, and find and fix the reason for the crashes in the
pre-built binaries of Texinfo 4.13.  If this was texinfo-devel, then I
would be expected to be ready to fix the package on whose development
I work, but this is emacs-devel, and all I need is a no-fuss way of
producing the latest manuals as part of building Emacs.  I don't want
to be forced into hacking Texinfo for that.

> I can't help you find a solution for that.

I meant a solution within Emacs.  For example, how about using Latin-1
encoding, and leaving a couple of people whose names need characters
beyond that with their previous ASCII replacements?

Re: Typesetting non-ASCII names in Emacs manuals

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Glenn Morris <rgm@gnu.org>
>> I can't help you find a solution for that.
>
> I meant a solution within Emacs.  For example, how about using Latin-1
> encoding, and leaving a couple of people whose names need characters
> beyond that with their previous ASCII replacements?

What's wrong with the good old TeX/texinfo macros that produce the
correct letters?  There was only a single name that used a non-ASCII
character that would have to be fixed to use the right texinfo macro.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Typesetting non-ASCII names in Emacs manuals

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Glenn Morris <rgm@gnu.org>,  karl@freefriends.org,  emacs-devel@gnu.org
> Date: Wed, 09 Mar 2011 11:19:16 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Glenn Morris <rgm@gnu.org>
> >> I can't help you find a solution for that.
> >
> > I meant a solution within Emacs.  For example, how about using Latin-1
> > encoding, and leaving a couple of people whose names need characters
> > beyond that with their previous ASCII replacements?
> 
> What's wrong with the good old TeX/texinfo macros that produce the
> correct letters?

Which macros did you have in mind?

> There was only a single name that used a non-ASCII
> character that would have to be fixed to use the right texinfo macro.

Which name is that?

Re: Typesetting non-ASCII names in Emacs manuals

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Which macros did you have in mind?

All the ones that Glenn removed.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Typesetting non-ASCII names in Emacs manuals

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: rgm@gnu.org,  karl@freefriends.org,  emacs-devel@gnu.org
> Date: Wed, 09 Mar 2011 11:34:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Which macros did you have in mind?
> 
> All the ones that Glenn removed.

They don't produce the correct letters in the Info output.  That's
what the bug was about, and that's what Glenn wanted to fix, IIUC.

Re: Typesetting non-ASCII names in Emacs manuals

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> A solution for the warning and -- more importantly -- for producing an
> Info file that doesn't render correctly (because it has no coding
> cookie, since makeinfo 4.8 didn't recognize the document encoding).

> And if "a few odd characters" is not an issue, then why make this
> change at all?  It was, after all, to fix "a few odd characters" in
> the names of some contributors, wasn't it?

Surely the cost of an extra warning for old versions of makeinfo is
worth it if users of newer versions of makeinfo can have the "odd
character" problem fixed.

Re: Typesetting non-ASCII names in Emacs manuals

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Cc: Glenn Morris <rgm@gnu.org>,  karl@freefriends.org,  emacs-devel@gnu.org
> Date: Wed, 09 Mar 2011 22:19:11 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > A solution for the warning and -- more importantly -- for producing an
> > Info file that doesn't render correctly (because it has no coding
> > cookie, since makeinfo 4.8 didn't recognize the document encoding).
> 
> > And if "a few odd characters" is not an issue, then why make this
> > change at all?  It was, after all, to fix "a few odd characters" in
> > the names of some contributors, wasn't it?
> 
> Surely the cost of an extra warning for old versions of makeinfo is
> worth it if users of newer versions of makeinfo can have the "odd
> character" problem fixed.

How about the cost of seeing the names garbled (see above)?

Re: Typesetting non-ASCII names in Emacs manuals

[Stefan Monnier]

> How about the cost of seeing the names garbled (see above)?

They were garbled before as well, IIUC (tho differently).


        Stefan

Re: Typesetting non-ASCII names in Emacs manuals

[Juanma Barranquero]

On Wed, Mar 9, 2011 at 15:19, Jason Rumney <jasonr@gnu.org> wrote:

> Surely the cost of an extra warning for old versions of makeinfo is
> worth it if users of newer versions of makeinfo can have the "odd
> character" problem fixed.

Well, it's not just an extra warning. Non-ASCII latin names are
garbled right now on Windows, at least if you use makeinfo 4.8.

And that "old version" of makeinfo is the current, non-buggy one.

    Juanma

Re: Typesetting non-ASCII names in Emacs manuals

[Juanma Barranquero]

> Well, it's not just an extra warning. Non-ASCII latin names are

s/latin //;

    Juanma

Re: Typesetting non-ASCII names in Emacs manuals

[Jason Rumney]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Wed, Mar 9, 2011 at 15:19, Jason Rumney <jasonr@gnu.org> wrote:
>
>> Surely the cost of an extra warning for old versions of makeinfo is
>> worth it if users of newer versions of makeinfo can have the "odd
>> character" problem fixed.
>
> Well, it's not just an extra warning. Non-ASCII latin names are
> garbled right now on Windows, at least if you use makeinfo 4.8.

Right, but without the change you and Eli are objecting to, they're
garbled for everyone, aren't they?

Re: Typesetting non-ASCII names in Emacs manuals

[Juanma Barranquero]

On Wed, Mar 9, 2011 at 16:21, Jason Rumney <jasonr@gnu.org> wrote:

> Right, but without the change you and Eli are objecting to, they're
> garbled for everyone, aren't they?

That does not mean that Glenn's is the right fix, that means that we
should try to find a fix for everyone.

Also, after the change, the files lie by saying that they are UTF-8,
but they are not (for Eli and me, at least); they contain raw bytes.

    Juanma

Re: Typesetting non-ASCII names in Emacs manuals

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  karl@freefriends.org
> Date: Wed, 09 Mar 2011 23:21:45 +0800
> 
> > Well, it's not just an extra warning. Non-ASCII latin names are
> > garbled right now on Windows, at least if you use makeinfo 4.8.
> 
> Right, but without the change you and Eli are objecting to, they're
> garbled for everyone, aren't they?

No, they aren't garbled.

Re: Typesetting non-ASCII names in Emacs manuals

[Eli Zaretskii]

> Date: Wed, 09 Mar 2011 03:45:17 -0500
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: karl@freefriends.org, emacs-devel@gnu.org
> 
> how about using Latin-1 encoding, and leaving a couple of people
> whose names need characters beyond that with their previous ASCII
> replacements?

I did this now.  In the ELisp manual, all the non-ASCII names can use
Latin-1, while in the Emacs User manual, I needed to use @-commands
for only 4 characters that are outside Latin-1.

Re: Typesetting non-ASCII names in Emacs manuals

[Glenn Morris]

Eli Zaretskii wrote:

> I did this now.  In the ELisp manual, all the non-ASCII names can use
> Latin-1, while in the Emacs User manual, I needed to use @-commands
> for only 4 characters that are outside Latin-1.

make emacs.pdf now fails on RHEL5:

Character missing in OT1 encoding: YEN SIGN.
doc/emacs/emacs.texi:1358: Undefined control sequence.
l.1358 Buehler, W

Character missing in OT1 encoding: CURRENCY SIGN.
doc/emacs/emacs.texi:1372: Undefined control sequence.
l.1372 ...angelo Grigni, Odd Gripenstam, Kai Gro

doc/emacs/emacs.texi:1383: Undefined control sequence.
l.1383 Kl, Kobayashi, Pavel Kobiakov, Larry K.@:

etc.

Re: Typesetting non-ASCII names in Emacs manuals

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: karl@freefriends.org,  emacs-devel@gnu.org
> Date: Wed, 09 Mar 2011 14:43:28 -0500
> 
> Eli Zaretskii wrote:
> 
> > I did this now.  In the ELisp manual, all the non-ASCII names can use
> > Latin-1, while in the Emacs User manual, I needed to use @-commands
> > for only 4 characters that are outside Latin-1.
> 
> make emacs.pdf now fails on RHEL5:
> 
> Character missing in OT1 encoding: YEN SIGN.
> doc/emacs/emacs.texi:1358: Undefined control sequence.
> l.1358 Buehler, W
> 
> Character missing in OT1 encoding: CURRENCY SIGN.
> doc/emacs/emacs.texi:1372: Undefined control sequence.
> l.1372 ...angelo Grigni, Odd Gripenstam, Kai Gro
> 
> doc/emacs/emacs.texi:1383: Undefined control sequence.
> l.1383 Kl, Kobayashi, Pavel Kobiakov, Larry K.@:

Sorry, brain fart.  Please try again.

Re: Typesetting non-ASCII names in Emacs manuals

[Glenn Morris]

Now it fails with:

./search.texi:927: Undefined control sequence.
<)}]*^^M
@doverbatim #1^^M#2@end verbatim->#2
                                    @end verbatim
l.927 @end verbatim
                   
argument> [.?!][]\"


Looks like some utf-8 characters snuck in there a while ago.
(They seem to be present in at least Emacs 23.1. So this suggests that
utf-8 chars in the manuals weren't causing any major issues.)

Re: Typesetting non-ASCII names in Emacs manuals

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: karl@freefriends.org,  emacs-devel@gnu.org
> Date: Wed, 09 Mar 2011 15:19:48 -0500
> 
> 
> Now it fails with:
> 
> ./search.texi:927: Undefined control sequence.
> <)}]*^^M
> @doverbatim #1^^M#2@end verbatim->#2
>                                     @end verbatim
> l.927 @end verbatim
>                    
> argument> [.?!][]\"
> 
> 
> Looks like some utf-8 characters snuck in there a while ago.

I would simply remove the offending quote.  It doesn't serve any
useful purpose in this case.  Do you want me to do that?

> So this suggests that utf-8 chars in the manuals weren't causing any
> major issues.

Sheer luck in this case (Emacs guesses that this is a UTF-8 encoding).

Re: Typesetting non-ASCII names in Emacs manuals

[Glenn Morris]

Eli Zaretskii wrote:

> I would simply remove the offending quote.  It doesn't serve any
> useful purpose in this case.  Do you want me to do that?

If you like; but there are more: mule.texi:240, building.texi:1059, ...

Re: Typesetting non-ASCII names in Emacs manuals

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: karl@freefriends.org,  emacs-devel@gnu.org
> Date: Wed, 09 Mar 2011 16:02:53 -0500
> 
> Eli Zaretskii wrote:
> 
> > I would simply remove the offending quote.  It doesn't serve any
> > useful purpose in this case.  Do you want me to do that?
> 
> If you like; but there are more: mule.texi:240, building.texi:1059, ...

Can't say that I like, but no one else seems to care.

Fixed (revno 103613 on the trunk).

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Juanma Barranquero]

On Wed, Mar 9, 2011 at 09:03, Glenn Morris <rgm@gnu.org> wrote:

> So I guess the problem is the apparent lack of a readily available
> working pre-built binary of a recent version of texinfo on MS Windows.

No, that's just what motivated my report.

The problem is changing things for minor issues and suddenly forcing
people (not just developers, but people who build from the source
tarball) to upgrade their setup, if at all possible. We are generally
very conservative with prerequisites, and for a good reason.

So, please, let's revert the change and look at the alternatives.

    Juanma

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Glenn Morris]

Juanma Barranquero wrote:

> The problem is changing things for minor issues and suddenly forcing
> people (not just developers, but people who build from the source
> tarball) to upgrade their setup, if at all possible.

(Pre)release tarfiles come with pre-built info files, so makeinfo is not
required at all in such cases.

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Juanma Barranquero]

On Wed, Mar 9, 2011 at 20:35, Glenn Morris <rgm@gnu.org> wrote:

> (Pre)release tarfiles come with pre-built info files, so makeinfo is not
> required at all in such cases.

You're right. "People who build from the repository", then.

    Juanma

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Juanma Barranquero]

On Tue, Mar 8, 2011 at 20:19, Glenn Morris <rgm@gnu.org> wrote:

> There is indeed a gripe when running `make info':
>
>  warning: unrecognized encoding name `UTF-8'.
>
> but an info file is still produced and the command exits with status 0.

These info files contain raw bytes:

   * Jan Dj\303\244rv added support for the GTK+ toolkit and X drag-and-drop.

   * Torbj\303\266rn Einarsson wrote `f90.el', a mode for Fortran 90 files.

etc.

    Juanma

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Jason Rumney]

On 09/03/2011 07:32, Juanma Barranquero wrote:
> On Tue, Mar 8, 2011 at 20:19, Glenn Morris<rgm@gnu.org>  wrote:
>
>    
>> There is indeed a gripe when running `make info':
>>
>>   warning: unrecognized encoding name `UTF-8'.
>>
>> but an info file is still produced and the command exits with status 0.
>>      
> These info files contain raw bytes:
>
>     * Jan Dj\303\244rv added support for the GTK+ toolkit and X drag-and-drop.
>
>     * Torbj\303\266rn Einarsson wrote `f90.el', a mode for Fortran 90 files.
>    

I'm not sure I understand the distinction between raw bytes and properly 
encoded text when talking about file contents.  Those byte values do 
appear to be the correct UTF-8 encoding if I am not mistaken.

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Juanma Barranquero]

On Thu, Mar 10, 2011 at 04:40, Jason Rumney <jasonr@gnu.org> wrote:

> I'm not sure I understand the distinction between raw bytes and properly
> encoded text when talking about file contents.  Those byte values do appear
> to be the correct UTF-8 encoding if I am not mistaken.

Emacs doesn't think so, because trying to save such info file gives a
message that the file cannot be encoded in utf-8-dos.

    Juanma

Re: Emacs-diffs Digest, Vol 100, Issue 28

[Eli Zaretskii]

> Date: Thu, 10 Mar 2011 11:40:10 +0800
> From: Jason Rumney <jasonr@gnu.org>
> 
> > These info files contain raw bytes:
> >
> >     * Jan Dj\303\244rv added support for the GTK+ toolkit and X drag-and-drop.
> >
> >     * Torbj\303\266rn Einarsson wrote `f90.el', a mode for Fortran 90 files.
> >    
> 
> I'm not sure I understand the distinction between raw bytes and properly 
> encoded text when talking about file contents.  Those byte values do 
> appear to be the correct UTF-8 encoding if I am not mistaken.

Visit the file and then look at the mode line's encoding mnemonics:
you will see "t" there, meaning that Emacs is not decoding the bytes.
What Juanma meant to say that the above is displayed as octal escapes.