GNU bug report logs -
#16292
24.3.50; info docs now contain single straight quotes instead of `'
Previous Next
Reported by: Gregor Zattler <grfz <at> gmx.de>
Date: Sun, 29 Dec 2013 22:10:01 UTC
Severity: wishlist
Found in version 24.3.50
Fixed in version 24.4
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16292 in the body.
You can then email your comments to 16292 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 29 Dec 2013 22:10:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Gregor Zattler <grfz <at> gmx.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 29 Dec 2013 22:10:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Dear emacs developers,
when I do a `make docs' the generated info files do not contain
`' -quotes any more but '' -quotes.
This breaks e.g. info+ fontification (a very helpful feature).
Reason is makeinfo >=5 produces either single straight quotes for
info files or single curly ones, depending on the document
encoding:
(from makeinfo maunal:)
'OPEN_QUOTE_SYMBOL'
When an opening quote is needed, e.g., for '@samp' output, use the
specified character; default '‘' for HTML, '‘' for
Docbook. For Info, the default depends on the enabled document
encoding (*note @documentencoding::); if no document encoding
is set, or the encoding is US-ASCII, etc., ''' is used.
This character usually appears as an undirected single quote
on modern systems. If the document encoding is Unicode, the
Info output uses a Unicode left quote.
[...]
(from makeinfo maunal:)
17.2 '@documentencoding ENC': Set Input Encoding
================================================
The '@documentencoding' command declares the input document encoding.
Write it on a line by itself, with a valid encoding specification
following, near the beginning of the file but after '@setfilename'
(*note @setfilename::):
@documentencoding ENC
At present, Texinfo supports only these encodings:
'US-ASCII'
This has no particular effect, but it's included for completeness.
'UTF-8'
The vast global character encoding, expressed in 8-bit bytes.
'ISO-8859-2'
'ISO-8859-1'
'ISO-8859-15'
[...]
Searching texinfos mailing list archives showed that this was
discussed roughly two years before and that it is the result of a
decision to go the same way as the rest of the world which
interprets ` as grave accent:
http://article.gmane.org/gmane.comp.tex.texinfo.bugs/5526/match=single+quotes :
|> For the record, RFC20 says the meaning of character 0x60 is
|> EITHER "grave accent" OR "opening single quotation mark". It
|> then says this character ".. should not be used without
|> determining that there is agreement between sender and recipient"
I think it's highly desirable to be able to tell beginning and
closing of enclosing characters apart. Therefore I consider the
info files single straight quotes a bug. I assume there is a way
to produce `' quotations with modern makeinfo or the *.texi files
should have @documentencoding directives which produce single
curly quotes.
Thanks for your attention, Gregor
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 01:15:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 16292 <at> debbugs.gnu.org (full text, mbox):
I think the Emacs manuals should use whatever Texinfo produces by default.
If that is '' rather than `', so be it. The place to argue for a change
would be the Texinfo list, but it sounds like that ship sailed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 03:08:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> I think the Emacs manuals should use whatever Texinfo produces by default.
> If that is '' rather than `', so be it. The place to argue for a change
> would be the Texinfo list, but it sounds like that ship sailed.
Emacs Dev has nothing to say about the format used for Info? Interesting.
Too bad, truly.
Emacs has a long tradition of font-locking `...' in doc strings. Why?
The reason for that (readability) is an even stronger argument for doing
the same for Info, where it matters even more.
And that would have been a good argument for Texinfo to keep the `...'
syntax for Info. Alas, Emacs Dev has never wanted to highlight `...'
in Info (even as a user option, and even though patches were available).
Again, too bad. Poor Emacs.
[This is like changing Lisp to use )lambda )var) )1+ )foo 42 var))) or XML
to use >foo>. Good candidates for an April Fool's joke; nothing more.]
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Mon, 30 Dec 2013 03:24:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Gregor Zattler <grfz <at> gmx.de>:
bug acknowledged by developer.
(Mon, 30 Dec 2013 03:24:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 16292-done <at> debbugs.gnu.org (full text, mbox):
Apparently the problem is that some of Emacs's .texi files
contain @documentencoding directives and generate curly quotes,
while others don't and generate straight quotes. It's better to
be consistent, and curly quotes seem more useful, so I installed
a patch to do that as trunk bzr 115807. I assume this fixes the
bug and so am closing this bug report; if it's not fixed please
let me know.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 03:27:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Drew Adams wrote:
> Emacs Dev has nothing to say about the format used for Info? Interesting.
>
> Too bad, truly.
>
> Emacs has a long tradition of font-locking `...' in doc strings. Why?
> The reason for that (readability) is an even stronger argument for doing
> the same for Info, where it matters even more.
>
> And that would have been a good argument for Texinfo to keep the `...'
> syntax for Info. Alas, Emacs Dev has never wanted to highlight `...'
> in Info (even as a user option, and even though patches were available).
>
> Again, too bad. Poor Emacs.
Could you possibly stop talking like such a pompous jackass?
There is no such thing as "Emacs Dev". There are just people, with
differing opinions, doing work, for free.
My opinion is that the Texinfo maintainers are the people who decide
what Info documents look like.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 04:11:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 16292-done <at> debbugs.gnu.org (full text, mbox):
> Apparently the problem is that some of Emacs's .texi files
> contain @documentencoding directives and generate curly quotes,
> while others don't and generate straight quotes. It's better to
> be consistent, and curly quotes seem more useful, so I installed
> a patch to do that as trunk bzr 115807. I assume this fixes the
> bug and so am closing this bug report; if it's not fixed please
> let me know.
Curly opening and closing quotes are certainly better than having
the same kind of quote char for both opening and closing. Thx.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 17:25:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 29 Dec 2013 19:23:32 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> Apparently the problem is that some of Emacs's .texi files
> contain @documentencoding directives and generate curly quotes,
> while others don't and generate straight quotes. It's better to
> be consistent, and curly quotes seem more useful, so I installed
> a patch to do that as trunk bzr 115807. I assume this fixes the
> bug and so am closing this bug report; if it's not fixed please
> let me know.
Very sorry, but I reverted that commit: it screws up anyone who wants
to read the docs on a text terminal that doesn't support UTF-8. At
best, you see something like
Hash notation cannot be read at all, so the Lisp reader signals the
error \u2018invalid-read-syntax\u2019 whenever it encounters \u2018#<\u2019.
At worst, you see this kind of gibberish:
In most cases, an objectΓאשs printed representation is also a read
syntax for the object. However, some types have no read syntax, since
it does not make sense to enter objects of these types as constants in a
Lisp program. These objects are printed in "hash notation", which
consists of the characters Γאר#<Γאש, a descriptive string (typically the
type name followed by the name of the object), and a closing Γאר>Γאש. For
example:
(current-buffer)
Γחע #<buffer objects.texi>
I'm sorry, we cannot possibly distribute documentation that looks like
this in some locales. For Emacs Info reader, we could perhaps fix
that by using a display table, but there's no such solution available
for the stand-alone Info reader that is part of Texinfo.
This change should have never been committed without a discussion,
certainly not during a feature freeze.
Of course, before this commit, we already had such a problem in
several files, which started using UTF-8 encoding since the last
March. But that, too, was never discussed AFAIR, and its effect on
@code, @samp, etc. markup, as well as on ``..'' quoted text, was never
mentioned. (These effects are barely documented in the Texinfo
manual, so it was easy to miss the meaning of those changes. I
submitted a bug report to Texinfo maintainers about this documentation
deficiency.)
So now we are left with a few files that still specify UTF-8, and
still screw up text-mode Info readers in some locales. Those files
were using Latin-1 before the changes in March 2013, which allowed us
to display a few non-ASCII words in Latin locales, but still have the
quotes and markup legible in all locales.
So, unless someone has a better idea, I will in a day or two revert
those files back to Latin-1. This will not be optimal, since names of
some people (I counted 4) mentioned in at least one of those files
cannot be encoded in Latin-1, and so we will need to use the ASCII
imitation offered by Texinfo (as we did before the switch to UTF-8).
But that is IMO a lesser evil than denying legible manuals to various
non-UTF locales.
As for the OP's report: I agree with Glenn that the ship with `..'
quoting in Info sailed a long time ago. I was against that change in
Texinfo (as was Karl Berry, one of the main Texinfo developers), but
this was voted down, so there's no sense in arguing about that. If
info+ needs to parse the quoting to highlight marked-up text, it will
have to adapt, sorry. (Or lobby on the Texinfo list for reverting to
previous behavior.)
I'm going to reopen the bug.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 30 Dec 2013 17:26:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 17:34:01 GMT)
Full text and
rfc822 format available.
Message #30 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Very sorry, but I reverted that commit...
>
> As for the OP's report: I agree with Glenn that the ship with `..'
> quoting in Info sailed a long time ago. I was against that change in
> Texinfo (as was Karl Berry, one of the main Texinfo developers), but
> this was voted down, so there's no sense in arguing about that. If
> info+ needs to parse the quoting to highlight marked-up text, it will
> have to adapt, sorry. (Or lobby on the Texinfo list for reverting to
> previous behavior.)
>
> I'm going to reopen the bug.
This is too bad, indeed.
I don't understand exactly what Paul did to change (for Emacs) the
first ' in '...' to SINGLE TURNED COMMA QUOTATION MARK, but if he
could do that, couldn't a similar approach be used to change that
first ' back to `, restoring things for Emacs users as they were
before (removing this regression)?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 18:05:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 30 Dec 2013 09:33:47 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: grfz <at> gmx.de, 16292 <at> debbugs.gnu.org
>
> I don't understand exactly what Paul did to change (for Emacs) the
> first ' in '...' to SINGLE TURNED COMMA QUOTATION MARK
Paul added "@documentencoding utf-8" to sources of all the Info
manuals; the rest was done by makeinfo when it produced the Info
files.
> but if he could do that, couldn't a similar approach be used to
> change that first ' back to `, restoring things for Emacs users as
> they were before (removing this regression)?
Not by a similar approach, but we could indeed restore old behavior by
customizing makeinfo (the details are in the Texinfo manual, and were
quoted here by the OP). But we need to agree to that first, and I
very much doubt that such an agreement will be reached, given the GNU
Coding Standards and the general mindset.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 19:08:01 GMT)
Full text and
rfc822 format available.
Message #36 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> we cannot possibly distribute documentation that looks like
> this in some locales.
Yes we can. We've been distributing documentation like that for years.
Latin-1 markup (which you're advocating) is not legible in all locales.
It's not legible in Shift-JIS, for example. And I don't see how Latin-1
markup can work in a text reader in a UTF-8 locale.
> So now we are left with a few files that still specify UTF-8, and
> still screw up text-mode Info readers in some locales.
It's not just the few files that specify "@documentencoding UTF-8".
It's several other files that contain UTF-8 characters, files like
dbus.texi. These files are being mishandled now, because of the revert,
because makeinfo isn't being told what their encoding is. And the
first of these files that I found, namely dbus.texi, is specifically
talking about multibyte characters in its example, so converting it
to Latin-1 would destroy the point of that example.
I sympathize with the goal of producing .info files portable to
all locales, but this revert is not solving that problem and it is
making matters significantly worse in other areas. The other change
you're advocating (converting to Latin-1) would be worse yet.
Instead, I suggest undoing the revert, and adding something to
postprocess the info files, to produce ASCII-only info files.
These could be used in locales that don't grok UTF-8. Doing
this will avoid screwing up the documentation in .html and .pdf
formats. I'll volunteer to write that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 19:30:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 30 Dec 2013 11:07:02 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Latin-1 markup (which you're advocating) is not legible in all locales.
Yes, but Latin-1 characters are only used in a handful of words (names
of people), so using Latin-1 doesn't hamper users' ability to read the
manual in any way, because the quote characters are not affected.
Only the UTF-8 encoding also affects the quote characters, which are
used a lot in Info.
So Latin-1 is a much lesser evil.
> It's not just the few files that specify "@documentencoding UTF-8".
> It's several other files that contain UTF-8 characters, files like
> dbus.texi. These files are being mishandled now, because of the revert,
> because makeinfo isn't being told what their encoding is. And the
> first of these files that I found, namely dbus.texi, is specifically
> talking about multibyte characters in its example, so converting it
> to Latin-1 would destroy the point of that example.
The job is not yet finished, so naturally there are problems we need
to solve. I've just reverted the situation back to where it was
before, to the point where we should discuss the possible solutions
and choose the best one.
> I sympathize with the goal of producing .info files portable to
> all locales, but this revert is not solving that problem and it is
> making matters significantly worse in other areas.
The problem of quotes _is_ solved, in most of the Info files. Again,
I'm not claiming we should release the files in their present shape.
There's still work to be done, the question is what to do.
> The other change you're advocating (converting to Latin-1) would be
> worse yet.
I don't see why it would be worse, please elaborate.
> Instead, I suggest undoing the revert, and adding something to
> postprocess the info files, to produce ASCII-only info files.
> These could be used in locales that don't grok UTF-8. Doing
> this will avoid screwing up the documentation in .html and .pdf
> formats. I'll volunteer to write that.
Are you suggesting to produce 2 separate sets of Info files? That
could work, although it will be unusual (I don't think any other
project does that). But if we go that way, there's no need to
postprocess anything, just run makeinfo again with --disable-encoding
and direct the output to a different place.
If you suggest to have a single set of Info files, then I don't
understand the proposal, or how it would help.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 19:47:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 16292 <at> debbugs.gnu.org (full text, mbox):
The info reader should really recode the info file into the locale's
encoding on the fly (and info files should always be encoded in UTF-8).
It doesn't make sense any more to use Latin-1.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 20:09:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, grfz <at> gmx.de, 16292 <at> debbugs.gnu.org
> Date: Mon, 30 Dec 2013 20:46:16 +0100
>
> The info reader should really recode the info file into the locale's
> encoding on the fly (and info files should always be encoded in UTF-8).
You mean, the Emacs Info reader? It already does that on a TTY,
using terminal-coding-system. But the problem is that these Unicode
quotes cannot be encoded in most (all?) non-UTF encodings.
We could replace those characters via display tables.
But these solutions are only for the Emacs Info reader; the
stand-alone reader doesn't do anything like that, it simply dumps the
bytes to the screen, assuming the text is in the current locale's
encoding.
> It doesn't make sense any more to use Latin-1.
We originally produced ASCII emulations of the non-ASCII characters
used by the names of contributors in ack.texi etc., but then decided
to show them more respect by using Latin. That's how it all started.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 30 Dec 2013 20:36:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> But these solutions are only for the Emacs Info reader; the
> stand-alone reader doesn't do anything like that, it simply dumps the
> bytes to the screen, assuming the text is in the current locale's
> encoding.
That's what needs to be fixed, not the contents of the info files.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Tue, 31 Dec 2013 05:52:01 GMT)
Full text and
rfc822 format available.
Message #51 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab wrote:
> The info reader should really recode the info file into the locale's
> encoding on the fly (and info files should always be encoded in UTF-8).
> It doesn't make sense any more to use Latin-1.
Thanks, that is a good suggestion.
I requested that on bug-texinfo, here:
http://lists.gnu.org/archive/html/bug-texinfo/2013-12/msg00023.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Tue, 31 Dec 2013 05:59:01 GMT)
Full text and
rfc822 format available.
Message #54 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> (names of people) so using Latin-1 doesn't hamper users'
> ability to read the manual in any way
Most of the non-ASCII words are people's names, but many are not,
and often ASCIIfying these would hurt the manual.
These include symbols (e.g., "¬"), examples of encoding
("@samp{Naïve} is encoded as @samp{=?iso-8859-1?q?Na=EFve?=}"),
calendars ("Bahá'í"), the names of GNU programs ("真 Gnus"),
and configuration examples ("écrit" in email configuration).
Nowadays, on GNUish and POSIXish systems in the Emacs target
audience, there's more usage of UTF-8 than of Latin-1. On
Ubuntu and Fedora, for example, the default locale for US
English is en_US.utf8. Hence, converting info files to
Latin-1 would hurt standalone info users in the typical
setup on GNUish and POSIXish platforms.
Perhaps Microsoft Windows users are different, and typically
use Latin-1 or some other unibyte encoding. If so, then
until standalone 'info' is improved we can support those
users by converting the info files on Windows platforms,
before installing the files. Perhaps this could be a
configure-time option. Or, perhaps it's simpler to ask
these folks to use Emacs to read their info files for now.
In any event we shouldn't convert the manual source to
Latin-1; not only would this lose information, it would hurt
the typical standalone info use case on GNUish systems.
In the short run, we do need to add @documentencoding
directives to the manuals that are already using UTF-8,
since makeinfo is currently mishandling these manuals.
This isn't critical for the plain-ASCII manuals, and we
could defer changes to the plain-ASCII manuals to the next
version of Emacs if necessary, though I expect it's better
to format all the manuals consistently.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Tue, 31 Dec 2013 08:04:01 GMT)
Full text and
rfc822 format available.
Message #57 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: eggert <at> cs.ucla.edu, grfz <at> gmx.de, 16292 <at> debbugs.gnu.org
> Date: Mon, 30 Dec 2013 21:35:43 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > But these solutions are only for the Emacs Info reader; the
> > stand-alone reader doesn't do anything like that, it simply dumps the
> > bytes to the screen, assuming the text is in the current locale's
> > encoding.
>
> That's what needs to be fixed, not the contents of the info files.
I agree that this would be very good indeed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Tue, 31 Dec 2013 08:29:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 30 Dec 2013 21:58:31 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
>
> > (names of people) so using Latin-1 doesn't hamper users'
> > ability to read the manual in any way
>
> Most of the non-ASCII words are people's names, but many are not,
> and often ASCIIfying these would hurt the manual.
> These include symbols (e.g., "¬"), examples of encoding
> ("@samp{Naïve} is encoded as @samp{=?iso-8859-1?q?Na=EFve?=}"),
> calendars ("Bahá'í"), the names of GNU programs ("真 Gnus"),
> and configuration examples ("écrit" in email configuration).
I don't think we care about encoding of a handful of words, as long as
the bulk of the manual, including markup and quotes, is legible. I
only mentioned Latin-1 because it seemed to cover most of the
non-ASCII characters. But I don't insist on it. Neither do I insist
on a single-byte encoding of those few words and names; in particular,
UTF-8 will do -- but only for the non-ASCII text in the manuals.
> Nowadays, on GNUish and POSIXish systems in the Emacs target
> audience, there's more usage of UTF-8 than of Latin-1. On
> Ubuntu and Fedora, for example, the default locale for US
> English is en_US.utf8. Hence, converting info files to
> Latin-1 would hurt standalone info users in the typical
> setup on GNUish and POSIXish platforms.
It hurts them in a very small number of places, most or all of which
don't affect in any way the ability of the reader to read and
understand the presented material.
As I say above, I won't object to having the non-ASCII words encoded
in UTF-8, as long as it doesn't affect the (single and double) quote
characters, and any other characters/strings (like '#' and '=>') we
use for describing the Emacs and Lisp features.
The problem here is that @documentencoding is virulent when you use
UTF-8: it affects the quotes, not just non-ASCII text in the Texinfo
sources. This is unlike any other value of @documentencoding. And
that is the only problem that bothers me, and IMO should bother us
all.
Perhaps a possible solution would be to customize OPEN_QUOTE_SYMBOL
and CLOSE_QUOTE_SYMBOL (although I'm not sure it affects double
quotes), or edit the Info files with Sed to replace Unicode quote
characters with some ASCII characters. The rest of the non-ASCII text
can be left intact, in UTF-8.
> Perhaps Microsoft Windows users are different, and typically
> use Latin-1 or some other unibyte encoding.
This has nothing to do with Windows; I first hit the problem on a
GNU/Linux machine that was configured with a non-UTF locale. The
reason I never saw the problem since last March is that I still use
makeinfo from Texinfo 4.13, which doesn't affect the quote characters
when @documentencoding of UTF-8 is specified. So the Info files I
produce when I build Emacs don't suffer from this misfeature.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Thu, 02 Jan 2014 02:06:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 16292 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii wrote:
> Perhaps a possible solution would be ...
> edit the Info files with Sed to replace Unicode quote
> characters with some ASCII characters.
Here's a patch that does that. I'm attaching a file
'info-utf8.diff' that contains this patch combined
with the previous one, for ease of trying it out
against the trunk.
=== modified file 'ChangeLog'
--- ChangeLog 2014-01-01 07:43:34 +0000
+++ ChangeLog 2014-01-02 00:45:52 +0000
@@ -1,3 +1,13 @@
+2014-01-02 Paul Eggert <eggert <at> cs.ucla.edu>
+
+ Specify info encoding and language (Bug#16292).
+ * build-aux/cp-ascii: New file.
+ * configure.ac: New option --with-ascii-info, which configures
+ INSTALL_INFO_DATA.
+ * Makefile.in (INSTALL_INFO_DATA): New macro.
+ (install-info): Use it.
+ * INSTALL: Document --with-ascii-info.
+
2013-12-31 Fabrice Popineau <fabrice.popineau <at> supelec.fr>
* configure.ac (canonical, C_SWITCH_SYSTEM): Support a 64-bit
=== modified file 'INSTALL'
--- INSTALL 2014-01-01 07:43:34 +0000
+++ INSTALL 2014-01-02 00:44:33 +0000
@@ -327,6 +327,11 @@
even on hosts where a narrower type would do. With this option, on a
typical 32-bit host, Emacs integers have 62 bits instead of 30.
+Use --with-ascii-info to install ASCII-only info files instead of
+UTF-8. This makes the info files more readable in installations where
+non-UTF-8 locales are commonly used, at the cost of losing some
+information.
+
Use --enable-gcc-warnings to enable compile-time checks that warn
about possibly-questionable C code. This is intended for developers
and is useful with GNU-compatible compilers. On a recent GNU system
=== modified file 'Makefile.in'
--- Makefile.in 2014-01-01 07:43:34 +0000
+++ Makefile.in 2014-01-02 00:02:58 +0000
@@ -255,6 +255,7 @@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_INFO = @INSTALL_INFO@
+INSTALL_INFO_DATA = @INSTALL_INFO_DATA@
# By default, we uphold the dignity of our programs.
INSTALL_STRIP =
MKDIR_P = @MKDIR_P@
@@ -663,7 +664,8 @@
test "$(HAVE_MAKEINFO)" = "no" && test ! -f $$elt && continue; \
for f in `ls $$elt $$elt-[1-9] $$elt-[1-9][0-9] 2>/dev/null`; do \
(cd "$${thisdir}"; \
- ${INSTALL_DATA} ${srcdir}/info/$$f "$(DESTDIR)${infodir}/$$f"); \
+ ${INSTALL_INFO_DATA} ${srcdir}/info/$$f \
+ "$(DESTDIR)${infodir}/$$f"); \
[ -n "${GZIP_PROG}" ] || continue ; \
rm -f "$(DESTDIR)${infodir}/$$f.gz"; \
${GZIP_PROG} -9n "$(DESTDIR)${infodir}/$$f"; \
=== added file 'build-aux/cp-ascii'
--- build-aux/cp-ascii 1970-01-01 00:00:00 +0000
+++ build-aux/cp-ascii 2014-01-02 00:40:51 +0000
@@ -0,0 +1,83 @@
+#! /bin/sh
+# Copy an ASCIIfied version of SOURCE to DEST.
+
+# Copyright 2014 Free Software Foundation, Inc.
+
+# This file is part of GNU Emacs.
+
+# GNU Emacs is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# GNU Emacs is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
+
+# written by Paul Eggert
+
+
+# The ASCII output is designed for documentation in an environment
+# that cannot handle non-ASCII characters. Some information may be
+# lost in the process, and the number of characters and/or bytes may
+# change.
+
+LC_ALL=C
+export LC_ALL
+
+source=${1?}
+dest=${2?}
+
+sed <"$source" >"$dest" '
+ s/ / /g
+ s/¤/[CURRENCY SIGN]/g
+ s/©/(C)/g
+ s/¬/~/g
+ s/»/>>/g
+ s/À/A/g
+ s/Å/A/g
+ s/ß/ss/g
+ s/à/a/g
+ s/á/a/g
+ s/ä/ae/g
+ s/å/a/g
+ s/ç/c/g
+ s/è/e/g
+ s/é/e/g
+ s/ê/e/g
+ s/ì/i/g
+ s/í/i/g
+ s/ï/i/g
+ s/ò/o/g
+ s/ó/o/g
+ s/ö/oe/g
+ s/ø/o/g
+ s/ü/ue/g
+ s/ć/c/g
+ s/č/c/g
+ s/ł/l/g
+ s/ń/n/g
+ s/ő/o/g
+ s/Š/S/g
+ s/š/s/g
+ s/–/-/g
+ s/—/--/g
+ s/‘/'\''/g
+ s/’/'\''/g
+ s/“/"/g
+ s/”/"/g
+ s/•/*/g
+ s/…/.../g
+ s/→/->/g
+ s/↦/|->/g
+ s/⇒/=>/g
+ s/−/-/g
+ s/≡/==/g
+ s/⊣/-|/g
+ s/★/*/g
+ s/真/[CJK UNIFIED IDEOGRAPH-771F]/g
+'
=== modified file 'configure.ac'
--- configure.ac 2014-01-01 08:31:29 +0000
+++ configure.ac 2014-01-01 23:58:54 +0000
@@ -300,6 +300,9 @@
[don't compress some files (.el, .info, etc.) when installing. Equivalent to:
make GZIP_PROG= install])
+OPTION_DEFAULT_OFF([ascii-info],
+ [install ASCII info files instead of UTF-8])
+
AC_ARG_WITH([pkg-config-prog],dnl
[AS_HELP_STRING([--with-pkg-config-prog=FILENAME],
[file name of pkg-config for finding GTK and librsvg])])
@@ -973,6 +976,14 @@
AC_PATH_PROG(INSTALL_INFO, install-info, :,
$PATH$PATH_SEPARATOR/usr/sbin$PATH_SEPARATOR/sbin)
+
+if test "$with_ascii_info" != yes; then
+ INSTALL_INFO_DATA='$(INSTALL_DATA)'
+else
+ INSTALL_INFO_DATA='build-aux/cp-ascii'
+fi
+AC_SUBST([INSTALL_INFO_DATA])
+
dnl Don't use GZIP, which is used by gzip for additional parameters.
AC_PATH_PROG(GZIP_PROG, gzip)
=== modified file 'etc/ChangeLog'
--- etc/ChangeLog 2014-01-01 07:43:34 +0000
+++ etc/ChangeLog 2014-01-02 00:45:48 +0000
@@ -1,3 +1,8 @@
+2014-01-02 Paul Eggert <eggert <at> cs.ucla.edu>
+
+ Specify info encoding and language (Bug#16292).
+ * NEWS: Document --with-ascii-info.
+
2013-12-29 Paul Eggert <eggert <at> cs.ucla.edu>
Plain copy-file no longer chmods an existing destination (Bug#16133).
=== modified file 'etc/NEWS'
--- etc/NEWS 2014-01-01 07:43:34 +0000
+++ etc/NEWS 2014-01-02 00:44:15 +0000
@@ -38,6 +38,8 @@
and renamed to `--without-compress-install'. It now prevents compression
of _any_ files during installation.
+** The configure option `--with-ascii-info' installs ASCII-only info files.
+
** The configure option `--with-crt-dir' has been removed.
It is no longer needed, as the crt*.o files are no longer linked
specially.
[info-utf8.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Thu, 02 Jan 2014 03:43:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 01 Jan 2014 18:05:16 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
> > Perhaps a possible solution would be ...
> > edit the Info files with Sed to replace Unicode quote
> > characters with some ASCII characters.
>
> Here's a patch that does that. I'm attaching a file
> 'info-utf8.diff' that contains this patch combined
> with the previous one, for ease of trying it out
> against the trunk.
Thanks, but this should be the default, or at least should be used
when producing the release tarball.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Thu, 02 Jan 2014 04:20:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Of course, before this commit, we already had such a problem in
> several files, which started using UTF-8 encoding since the last
> March. But that, too, was never discussed AFAIR, and its effect on
> @code, @samp, etc. markup, as well as on ``..'' quoted text, was never
> mentioned. (These effects are barely documented in the Texinfo
> manual, so it was easy to miss the meaning of those changes.
I think it's not just a documentation error. There's no good reason to
link the input document encoding to the kind of symbols used in the output.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Thu, 02 Jan 2014 04:49:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> There's no good reason to link the input document encoding
> to the kind of symbols used in the output.
I agree. That's another bug report I suppose I should file with bug-texinfo,
I suppose.
By the way, this isn't something that began with my changes in March,
as Eli suggested earlier. Emacs 24.3 shipped with some .info files in
UTF-8 and others in Latin-1, which means that in pretty much any locale,
standalone 'info' will misbehave on some Emacs info file or another.
The problem goes back at least to Emacs 23.1 in 2009 (that's as far back
as I cared to check).
This latter bug, too, is fixed by the latest proposed patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Thu, 02 Jan 2014 04:51:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Thanks, but this should be the default, or at least should be used
> when producing the release tarball.
No, the point is that the release tarball contains UTF-8
info files, and that these are transformed to ASCII for installations
that prefer ASCII info files. cp-ascii's UTF8-to-ASCII transformation
loses information; we can't ship ASCII info files in the tarball
and then transform those to the UTF-8 originals.
An ASCII default would have been better years ago, but these days
UTF-8 is the typical default encoding in GNUish distributions and
most users will be better off if UTF-8 is the default.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Thu, 02 Jan 2014 15:30:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 01 Jan 2014 20:48:49 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: grfz <at> gmx.de, 16292 <at> debbugs.gnu.org
>
> Stefan Monnier wrote:
>
> > There's no good reason to link the input document encoding
> > to the kind of symbols used in the output.
>
> I agree. That's another bug report I suppose I should file with bug-texinfo,
> I suppose.
Yes. Although the makeinfo maintainer doesn't seem to share this view.
> By the way, this isn't something that began with my changes in March,
> as Eli suggested earlier. Emacs 24.3 shipped with some .info files in
> UTF-8 and others in Latin-1, which means that in pretty much any locale,
> standalone 'info' will misbehave on some Emacs info file or another.
> The problem goes back at least to Emacs 23.1 in 2009 (that's as far back
> as I cared to check).
That's true, but until Texinfo 5 came and changed the effect of
@documentencoding, this hardly mattered, as the non-ASCII characters
in those few manuals (I found 4) were extremely rare, something like 2
to 5 per manual.
The important thing (to me) is to have the markup, quotes, and arrows
displayable, because that's the bulk of the manual.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Thu, 02 Jan 2014 15:52:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 01 Jan 2014 20:50:16 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
> > Thanks, but this should be the default, or at least should be used
> > when producing the release tarball.
>
> No, the point is that the release tarball contains UTF-8
> info files, and that these are transformed to ASCII for installations
> that prefer ASCII info files.
But does "make install" really cut that? How many end users on a
typical Posix platform will build and install their own Emacs? I
thought the majority installs from ready-to-run packages nowadays, and
in that case "make install" was already run by someone else, with who
knows what configure-time options.
> cp-ascii's UTF8-to-ASCII transformation loses information; we can't
> ship ASCII info files in the tarball and then transform those to the
> UTF-8 originals.
That's because your Sed script goes too far, IMO: it can be limited to
editing only the markup and the => arrows, and leave the other
non-ASCII characters intact. Then there will be no information loss,
just a different (some will say less pretty) display of that
information.
> An ASCII default would have been better years ago, but these days
> UTF-8 is the typical default encoding in GNUish distributions and
> most users will be better off if UTF-8 is the default.
I agree, when it comes to non-ASCII text. But I see no reason for
such a strong preference when it comes to the Info markup. I find
that a purely aesthetic consideration with no real functionality
behind it. (It can even hurt: e.g., on one of my machines, the
Unicode quotes look pale and not so pretty at all, I guess the font
I'm using is not the best one for those characters.)
To summarize, I see the following possible ways to solve this issue:
1) Do nothing. This is a temporary measure at best and doesn't make
much sense; I mention it here only for completeness. Sooner or
later we will have to do something.
2) Use "@documentencoding ISO-8859-1" in any manual that needs to
include non-ASCII characters. This is what we did a year ago,
although a couple of manuals had utf-8 in them; they can all be
converted to use Latin-1. The advantage is that this leaves the
markup intact; the disadvantage is that most locales will not
display the non-ASCII text correctly these days.
3) Install Paul's script, which will be run at "make install" time,
either by default, or given a configure time option. (We could
also make this "make install" time option.) If we go this way,
I think we should leave Unicode characters that are not Info
markup alone, and not edit them.
4) Use --disable-encoding switch to makeinfo, again either by
default or given some non-default option. This avoids the need
for a separate Sed script, but has a complication: makeinfo 4.13,
which I presume is still in use and which we want to support, did
not emit the 'coding' cookie when --disable-encoding was
specified. OTOH, makeinfo 4.13 didn't emit Unicode quotes when
--enable-encoding was specified. So if we go this way, we will
need to detect the makeinfo version and use the right switch.
5) Add a feature to info.el that will set up a display table for
Info buffers, and use that display table to display quotes and
arrows on TTYs that don't support UTF-8. Then Paul's changes to
use "@documentencoding utf-8" everywhere can be re-installed with
no additional changes. However, unlike all the other
alternatives, this one solves the problem only for the Emacs Info
reader, and leaves the problem with the stand-alone Info reader
to the Texinfo maintainers.
If someone has other suggestions, please raise them. Otherwise, I
guess it's decision time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Thu, 02 Jan 2014 19:29:01 GMT)
Full text and
rfc822 format available.
Message #84 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> I thought the majority installs from ready-to-run packages nowadays, and
> in that case "make install" was already run by someone else, with who
> knows what configure-time options.
Yes, that's right. Since GNU/Linux distributors typically
ship UTF-8 locales, the UTF-8 default should work. If any
distributors want to cater to users in unibyte locales, they
can enable the option to ship ASCIIfied info files in their
packages. I think few will, but I've been wrong before....
> it can be limited to editing only the markup and the => arrows, and
> leave the other non-ASCII characters intact. Then there will be no
> information loss, just a different (some will say less pretty)
> display of that information.
There would still be information loss; we'll lose the
distinction between open and close quote, for example. The
calc info file will contain "'f''2'3(x,y,z)'", for example.
Sure, a reader can eventually puzzle out which of
those apostrophes is meant to be an open single quote, close
single quote, and apostrophe (there are some of each), but
it's better if the documentation doesn't puzzle the reader.
This is the main argument for using directed quotes in the
Info files, as I see it. Aesthetics are nice but are
secondary.
> To summarize, I see the following possible ways to solve this issue:
>
> 1) Do nothing. This is a temporary measure at best and doesn't make
> much sense; I mention it here only for completeness. Sooner or
> later we will have to do something.
Agreed.
> 2) Use "@documentencoding ISO-8859-1" in any manual that needs to
> include non-ASCII characters. This is what we did a year ago,
> although a couple of manuals had utf-8 in them; they can all be
> converted to use Latin-1. The advantage is that this leaves the
> markup intact; the disadvantage is that most locales will not
> display the non-ASCII text correctly these days.
That is a fatal objection nowadays. Another disadvantage is
that some manuals contain non-Latin-1 characters. We could
rework them ("Latin-1-ify the manuals"), but this is heading in
the wrong direction.
> 3) Install Paul's script, which will be run at "make install" time,
> either by default, or given a configure time option. (We could
> also make this "make install" time option.)
My latest proposed patch causes this to be both a
configure-time option "configure --with-ascii-info" and a
make-time option "make INSTALL_INFO_DATA=build-aux/cp-ascii install".
So this approach is already implemented.
> If we go this way, I think we should leave Unicode characters
> that are not Info markup alone, and not edit them.
build-aux/cp-ascii cannot reliably distinguish Info-markup
Unicode from other Unicode, so I don't see how to implement
this precisely. We could implement an approximation, but
why bother? The point of cp-ascii is to not put mojibake
on unibyte users' screens, so why not fix all the mojibake
while we're at it?
> 4) Use --disable-encoding switch to makeinfo, again either by
> default or given some non-default option.
This would lose information in the now-typical case of UTF-8 locales.
> 5) Add a feature to info.el that will set up a display table for
> Info buffers, and use that display table to display quotes and
> arrows on TTYs that don't support UTF-8. Then Paul's changes to
> use "@documentencoding utf-8" everywhere can be re-installed with
> no additional changes. However, unlike all the other
> alternatives, this one solves the problem only for the Emacs Info
> reader, and leaves the problem with the stand-alone Info reader
> to the Texinfo maintainers.
This would be a reasonable thing to do. It can be done
independently of (3).
Here's another option:
6) install the original patch as-is, i.e., not bother with ASCIIfying
the info files at all, and ask people to use UTF-8-aware software
to read info files. That would be simpler so I'd prefer it, but as
I understand it Eli really dislikes this approach. (3) is an acceptable
compromise.
I suggest installing (3) now, as it fixes known bugs. We
can implement (5) at our leisure. (I say "we" but really
mean "not me", as I am no expert at display tables....)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Thu, 02 Jan 2014 20:57:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 02 Jan 2014 11:28:17 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> > it can be limited to editing only the markup and the => arrows, and
> > leave the other non-ASCII characters intact. Then there will be no
> > information loss, just a different (some will say less pretty)
> > display of that information.
>
> There would still be information loss; we'll lose the
> distinction between open and close quote, for example. The
> calc info file will contain "'f''2'3(x,y,z)'", for example.
These are very rare (and I would argue will look ugly any way you
typeset them).
> > If we go this way, I think we should leave Unicode characters
> > that are not Info markup alone, and not edit them.
>
> build-aux/cp-ascii cannot reliably distinguish Info-markup
> Unicode from other Unicode, so I don't see how to implement
> this precisely.
Sorry, I don't see the problem: just don't edit any letters, only edit
apostrophes, quotes, and arrows. What am I missing?
> The point of cp-ascii is to not put mojibake on unibyte users'
> screens, so why not fix all the mojibake while we're at it?
To make it more acceptable to UTF-8 locales. If we leave the
non-ASCII text alone, we have a higher chance of producing a single
format that will be used both in UTF-8 and non-UTF-8 locales.
> > 4) Use --disable-encoding switch to makeinfo, again either by
> > default or given some non-default option.
>
> This would lose information in the now-typical case of UTF-8 locales.
Again, I don't see why, unless you refer to that example from Calc.
Otherwise, the only effect of --disable-encoding in Texinfo 5 is not
to produce Unicode characters for quotes and arrows.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 03 Jan 2014 00:45:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> These are very rare (and I would argue will look ugly any
> way you typeset them).
They're not that rare: for example, I count 949 info lines
containing both straight and the curly apostrophes, with
many opportunities for confusion. ‘C-x '’ may look ugly on
some displays, but it's typically legible, and it's
definitely easier to grok than 'C-x ''. The primary goal
here is conveying information, not beauty.
> I don't see the problem: just don't edit any letters, only edit
> apostrophes, quotes, and arrows. What am I missing?
Info generates lots of special characters like that, in
response to ASCII markup. From the unibyte reader's point
of view, why should the output of "``", "@quoteleft{}",
"@expansion{}", "@result{}", etc. be converted from mojibake
to ASCII, while the output of "--", "@bullet{}", "@minus{}",
"@equiv{}", "@~n", etc. remains mojibake? I don't see any
systematic principle to distinguish between the two sets of
characters.
>> The point of cp-ascii is to not put mojibake on unibyte users'
>> screens, so why not fix all the mojibake while we're at it?
>
> To make it more acceptable to UTF-8 locales.
UTF-8 locales work just fine (actually, better) with the
original UTF-8 characters, so it's not a priority for
cp-ascii's output to be more acceptable to UTF-8 locales.
It's fine if cp-ascii's output is just as acceptable for
UTF-8 locales as it is for ASCII locales.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 03 Jan 2014 08:04:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 02 Jan 2014 16:44:10 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
> > These are very rare (and I would argue will look ugly any
> > way you typeset them).
>
> They're not that rare: for example, I count 949 info lines
> containing both straight and the curly apostrophes, with
> many opportunities for confusion.
That's rare in my book: just the 2 Emacs manuals weigh in at 124800
lines.
> ‘C-x '’ may look ugly on some displays, but it's typically legible,
> and it's definitely easier to grok than 'C-x ''.
We've been living with `C-x'' forever, so I don't see a serious
problem here. And if we really care, we can customize
OPEN_QUOTE_SYMBOL in Texinfo 5.
> > I don't see the problem: just don't edit any letters, only edit
> > apostrophes, quotes, and arrows. What am I missing?
>
> Info generates lots of special characters like that, in
> response to ASCII markup. From the unibyte reader's point
> of view, why should the output of "``", "@quoteleft{}",
> "@expansion{}", "@result{}", etc. be converted from mojibake
> to ASCII, while the output of "--", "@bullet{}", "@minus{}",
> "@equiv{}", "@~n", etc. remains mojibake? I don't see any
> systematic principle to distinguish between the two sets of
> characters.
The systematic principle I propose is to convert everything except
letters, i.e. only punctuation and special characters.
> >> The point of cp-ascii is to not put mojibake on unibyte users'
> >> screens, so why not fix all the mojibake while we're at it?
> >
> > To make it more acceptable to UTF-8 locales.
>
> UTF-8 locales work just fine (actually, better) with the
> original UTF-8 characters, so it's not a priority for
> cp-ascii's output to be more acceptable to UTF-8 locales.
It would be a priority if we decide to make that cp-ascii'd output the
default.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 03 Jan 2014 17:27:03 GMT)
Full text and
rfc822 format available.
Message #96 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>>> These are very rare (and I would argue will look ugly any
>>> way you typeset them).
>>
>> They're not that rare: for example, I count 949 info lines
>> containing both straight and the curly apostrophes, with
>> many opportunities for confusion.
>
> That's rare in my book
Well, at least I appreciate the promotion from "very rare"
to "rare". :-) It's still too common for comfort.
> We've been living with `C-x '' forever
But we're migrating away from it, which is partly what
prompted this discussion. The question now is whether to
prefer ‘C-x '’ or 'C-x ''. Of the three notations,
‘C-x '’ is the least confusing, and 'C-x '' the most.
> And if we really care, we can customize
> OPEN_QUOTE_SYMBOL in Texinfo 5.
We should not really care about it. The Texinfo defaults are OK.
> The systematic principle I propose is to convert everything except
> letters, i.e. only punctuation and special characters.
From the viewpoint of the unibyte reader that's just weird.
Why should "ß" be converted to mojibake (destroying the point
of a code example) while "•" is converted to "*"
(a mere formatting nicety)?
To be honest, though, I think the whole idea of converting is
wrong, and as long as it's not the default I don't really
care. If people complain about the conversion I'll just
say "don't do the conversion". (Or send them to you. :-)
> It would be a priority if we decide to make that cp-ascii'd output the
> default.
That's not likely. The general consensus seems to be that
Emacs should just use whatever Texinfo produces by default.
The proper place to reargue what Texinfo does should be in
the Texinfo forums. Even cp-ascii goes too far, in my
opinion; I think we should just switch to UTF-8 and be
done with it. But I'm willing to go along with cp-ascii as
a compromise, so long as it's not the default.
If this turns into a problem in practice, and Emacs builders
and/or distributors enable the cp-ascii option more often than
not, we can change the default to use cp-ascii, and use this as
good evidence to argue for a change to 'makeinfo'. (This is an
unlikely scenario in my view.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 03 Jan 2014 20:19:02 GMT)
Full text and
rfc822 format available.
Message #99 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 03 Jan 2014 09:26:29 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> > The systematic principle I propose is to convert everything except
> > letters, i.e. only punctuation and special characters.
>
> From the viewpoint of the unibyte reader that's just weird.
> Why should "ß" be converted to mojibake (destroying the point
> of a code example) while "•" is converted to "*"
> (a mere formatting nicety)?
Because the former are rare in an otherwise English manual, and are
mostly in people's names, not in the stuff the manual tries to
describe. By contrast, the latter are many and directly affect the
readability of the manual.
> > It would be a priority if we decide to make that cp-ascii'd output the
> > default.
>
> That's not likely. The general consensus seems to be that
> Emacs should just use whatever Texinfo produces by default.
We didn't hear from Stefan yet. This isn't a democracy.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 03 Jan 2014 20:49:01 GMT)
Full text and
rfc822 format available.
Message #102 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> We didn't hear from Stefan yet. This isn't a democracy.
I expect Stefan is tired of the whole topic. I know I am.
Stefan's initial comment was "I'd much rather change
Texinfo to default to utf-8" -- a sentiment I agree with,
though that'll require changes to Texinfo. This
suggests a preference for UTF-8 encoded .texi files,
though not necessarily for UTF-8 encoded .info files.
Glenn and I have both expressed a preference for letting
makeinfo do its thing rather than try to second-guess it.
The only way that can be done with existing tools and
UTF-8 .texi files (without introducing some errors in the
output) is to specify @documentencoding UTF-8.
>> Date: Fri, 03 Jan 2014 09:26:29 -0800
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>> Why should "ß" be converted to mojibake (destroying the point
>> of a code example) while "•" is converted to "*"
>> (a mere formatting nicety)?
>
> Because the former are rare in an otherwise English manual, and are
> mostly in people's names, not in the stuff the manual tries to
> describe.
But they do exist outside of people's names, and in those cases
turning them to mojibake can make the content undecipherable.
Conversely, some of the symbols (such as "•") are relatively rare, and
transliterating them to mojibake typically doesn't hurt the content; after
all, the main role of "•" is to be a blotch at the start of a bullet
point, and pretty much any consistent blotch will do.
I still think it's Really Weird to transliterate some characters
to unibyte but not others, if the goal is to support unibyte
environments.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 03 Jan 2014 21:13:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 03 Jan 2014 12:48:50 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> > We didn't hear from Stefan yet. This isn't a democracy.
>
> I expect Stefan is tired of the whole topic.
It's his call.
> I know I am.
Then give up ;-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 03 Jan 2014 21:53:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 16292 <at> debbugs.gnu.org (full text, mbox):
>> That's not likely. The general consensus seems to be that
>> Emacs should just use whatever Texinfo produces by default.
> We didn't hear from Stefan yet. This isn't a democracy.
I'm not sure I understand all of the things discussed.
My position is as follows:
- I'd rather use Texinfo defaults, of course, to the extent that they
work OK for Emacs.
- We should feel free to use Unicode chars (in utf-8 encoding) in .texi files
(and utf-8 should be the default encoding, so there's no need to
specify it explicitly in the file).
- Those Unicode chars should be preserved in the .info files (i.e. Info
files should also use utf-8).
- The chars introduced by "makeinfo" itself should stick to ASCII for
now by default. I think we're pretty close to the point where ‘ and ’
can be assumed to work "everywhere", but we're not quite there yet.
But I'd hope that Debian builds would not follow that default and
would tell make info to use things like ‘ and ’ since these chars
should pretty much always work in a Debian system.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 00:08:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 16292 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier wrote:
> I think we're pretty close to the point where ‘ and ’
> can be assumed to work "everywhere", but we're not quite there yet.
> But I'd hope that Debian builds would not follow that default and
> would tell make info to use things like ‘ and ’ since these chars
> should pretty much always work in a Debian system.
OK, attached is a patch to implement that suggestion, with the proviso
that the default is to use curly quotes on Debian-like systems where
UTF-8 support seems ubiquitous, and to use ASCII quotes elsewhere.
This should simplify configuration on Debianish systems. The 'locale'
command is used to check for UTF-8 support in English.
This feels like a new feature, so I'm somewhat inclined to leave this
stuff alone in the trunk until after the feature freeze is over.
[info-utf8.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 00:41:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> This feels like a new feature, so I'm somewhat inclined to leave
> this stuff alone in the trunk until after the feature freeze is over.
As long as the regression is fixed, that sounds reasonable. IOW,
we already had a regression from `...' to '...'.
IIUC, Eli reverted that regression, restoring `...'. But if not,
then this should be fixed (somehow) before the release.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 00:50:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Drew Adams wrote:
> As long as the regression is fixed, that sounds reasonable. IOW,
> we already had a regression from `...' to '...'.
None of my patches, nor Eli's revert, affect
whether you get `...' as opposed to '...'.
That's a property of Texinfo, not of the Emacs source.
If you want `...', you can build with Texinfo 4.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 05:19:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 16292 <at> debbugs.gnu.org (full text, mbox):
>> I think we're pretty close to the point where ‘ and ’
>> can be assumed to work "everywhere", but we're not quite there yet.
>> But I'd hope that Debian builds would not follow that default and
>> would tell make info to use things like ‘ and ’ since these chars
>> should pretty much always work in a Debian system.
> OK, attached is a patch to implement that suggestion,
It doesn't quite follow the suggestion in the part about "so there's no
need to specify it explicitly in the file". Isn't there a way other
than modifying the file to tell Texinfo that the encoding is utf-8?
> with the proviso that the default is to use curly quotes on
> Debian-like systems where UTF-8 support seems ubiquitous, and to use
> ASCII quotes elsewhere.
By "Debian builds" I really meant "builds of Emacs made by the Debian
team", not "builds made under Debian".
> This should simplify configuration on Debianish systems. The 'locale'
> command is used to check for UTF-8 support in English.
I'd rather not try to be clever here. E.g. your test will end up using
ASCII in non-English locales, even though they're just as likely to
properly handle those Unicode chars. Just default to no.
> This feels like a new feature, so I'm somewhat inclined to leave this
> stuff alone in the trunk until after the feature freeze is over.
Agreed. One more thing: the config option might like to use a more
generic name like "--with-liberal-use-of-unicode".
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 07:29:01 GMT)
Full text and
rfc822 format available.
Message #123 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 3 Jan 2014 16:40:30 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: grfz <at> gmx.de, 16292 <at> debbugs.gnu.org
>
> > This feels like a new feature, so I'm somewhat inclined to leave
> > this stuff alone in the trunk until after the feature freeze is over.
>
> As long as the regression is fixed, that sounds reasonable. IOW,
> we already had a regression from `...' to '...'.
>
> IIUC, Eli reverted that regression, restoring `...'.
No, I didn't, not if Texinfo 5 is used to prepare the Info files. In
that version of Texinfo, the default is '..'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 07:39:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
> Date: Fri, 03 Jan 2014 16:52:01 -0500
>
> My position is as follows:
> - I'd rather use Texinfo defaults, of course, to the extent that they
> work OK for Emacs.
> - We should feel free to use Unicode chars (in utf-8 encoding) in .texi files
> (and utf-8 should be the default encoding, so there's no need to
> specify it explicitly in the file).
> - Those Unicode chars should be preserved in the .info files (i.e. Info
> files should also use utf-8).
> - The chars introduced by "makeinfo" itself should stick to ASCII for
> now by default. I think we're pretty close to the point where ‘ and ’
> can be assumed to work "everywhere", but we're not quite there yet.
> But I'd hope that Debian builds would not follow that default and
> would tell make info to use things like ‘ and ’ since these chars
> should pretty much always work in a Debian system.
That's my position as well. I think using --disable-encoding in
Texinfo 5 and --enable-encoding in older versions will achieve
precisely that. It is also simple and doesn't require any
configure-time options. All we need is a simple test in the Makefile
of the version of makeinfo being used.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 07:42:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 03 Jan 2014 16:07:32 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Stefan Monnier wrote:
>
> > I think we're pretty close to the point where ‘ and ’
> > can be assumed to work "everywhere", but we're not quite there yet.
> > But I'd hope that Debian builds would not follow that default and
> > would tell make info to use things like ‘ and ’ since these chars
> > should pretty much always work in a Debian system.
>
> OK, attached is a patch to implement that suggestion, with the proviso
> that the default is to use curly quotes on Debian-like systems where
> UTF-8 support seems ubiquitous, and to use ASCII quotes elsewhere.
Thanks.
However, I don't like system-specific defaults, and I think a
configure-time option to change this is a nuisance.
I think we should use --disable-encoding instead, and do it by
default. People who want Unicode quotes and other special characters
can always override that by specifying non-default MAKEINFO_OPTS at
"make info" time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 07:46:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
> Date: Sat, 04 Jan 2014 00:18:15 -0500
>
> Isn't there a way other than modifying the file to tell Texinfo that
> the encoding is utf-8?
No, not if you want makeinfo to put the 'coding' cookie in the file
local variables section of the Info file it produces.
@documentencoding is the way.
> I'd rather not try to be clever here. E.g. your test will end up using
> ASCII in non-English locales, even though they're just as likely to
> properly handle those Unicode chars. Just default to no.
I agree. And using --disable-encoding is a simpler way of achieving
that, as it doesn't need any postprocessing.
> > This feels like a new feature, so I'm somewhat inclined to leave this
> > stuff alone in the trunk until after the feature freeze is over.
>
> Agreed.
If so, we should at least fix the handful of manuals that already use
"@documentencoding utf-8", or use non-ASCII characters without any
@documentencoding, thus producing Info files that might display
incorrectly in certain locales.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 15:22:01 GMT)
Full text and
rfc822 format available.
Message #135 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> > > This feels like a new feature, so I'm somewhat inclined to leave
> > > this stuff alone in the trunk until after the feature freeze is
> > > over.
> >
> > As long as the regression is fixed, that sounds reasonable. IOW,
> > we already had a regression from `...' to '...'.
> >
> > IIUC, Eli reverted that regression, restoring `...'.
>
> No, I didn't, not if Texinfo 5 is used to prepare the Info files.
> In that version of Texinfo, the default is '..'.
My mistake.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 17:51:01 GMT)
Full text and
rfc822 format available.
Message #138 received at 16292 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier wrote:
> Isn't there a way other than modifying the file to tell
> Texinfo that the encoding is utf-8?
Not that I know of, no. Sorry.
> your test will end up using ASCII in non-English locales
No, because the test doesn't look at the current locale.
It looks at what locales are available.
That being said, the test could be improved to not care about
English; that's simpler anyway. I'll attach a revised patch,
which also fixes some other problems I noticed (e.g., some
'sed' implementations mishandle NUL bytes).
Defaulting to ASCII in all platforms would leave the original
bug unfixed by default on all installations, causing the
regression from `foo' to 'foo' that Drew Adams complained of.
I.e., on all platforms the Emacs documentation would default
to lower quality than it's had for decades. It's better to
default to ASCII only on platforms that don't support UTF-8
well.
> the config option might like to use a more
> generic name like "--with-liberal-use-of-unicode".
But it's not liberal: it's conservative! :-)
That is, it conserves the info file's contents.
Plus, it's UTF-8 not Unicode.
I tried names like '--with-some-utf-8-or-another' but
the 'utf-8-' makes it hard to parse visually, so I inverted the
flag to '--with-ascii-info-marks', which just barely fits in
'configure --help' output. This is included in the revised
patch.
[info-utf8.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 18:02:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> And using --disable-encoding is a simpler way of achieving
> that, as it doesn't need any postprocessing.
No, because we can't assume that the installer has 'makeinfo'
and can run 'makeinfo' with --disable-encoding. Instead, we must use
universally-available tools like 'sed' when installing.
> we should at least fix the handful of manuals that already use
> "@documentencoding utf-8", or use non-ASCII characters without any
> @documentencoding, thus producing Info files that might display
> incorrectly in certain locales.
None of that would fix the regression that Drew Adams noted.
Better would be to leave the files alone, and build the next
Emacs tarball with Texinfo 4. We can switch to Texinfo 5 for
building tarballs after the feature freeze is over.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 20:09:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Jan 2014 09:50:21 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: Eli Zaretskii <eliz <at> gnu.org>, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Defaulting to ASCII in all platforms would leave the original
> bug unfixed by default on all installations, causing the
> regression from `foo' to 'foo' that Drew Adams complained of.
That's not an Emacs problem. The Texinfo developers decided to make
that change, and they followed the GNU Coding Standards. Emacs needs
to adapt, as the rest of the GNU project did. If you think this is a
step backwards, you need to talk to the Texinfo developers.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 20:13:01 GMT)
Full text and
rfc822 format available.
Message #147 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Jan 2014 10:01:28 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
> > And using --disable-encoding is a simpler way of achieving
> > that, as it doesn't need any postprocessing.
>
> No, because we can't assume that the installer has 'makeinfo'
> and can run 'makeinfo' with --disable-encoding. Instead, we must use
> universally-available tools like 'sed' when installing.
I wasn't talking about the installers, I was talking about someone who
does the "make info" step. Of course, this being Free Software, any
end user can redo "make info" if the result is not to her liking. At
that time, she can override the defaults if she so wants.
> > we should at least fix the handful of manuals that already use
> > "@documentencoding utf-8", or use non-ASCII characters without any
> > @documentencoding, thus producing Info files that might display
> > incorrectly in certain locales.
>
> None of that would fix the regression that Drew Adams noted.
That regression is not our problem, and if we want to fix it in Emacs,
we can use one of the Emacs display features to display some
characters as some other characters.
> Better would be to leave the files alone, and build the next
> Emacs tarball with Texinfo 4.
I don't mind to use Texinfo 4, if there are no objections. It would
solve the problem that matters to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 20:25:02 GMT)
Full text and
rfc822 format available.
Message #150 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> > Better would be to leave the files alone, and build the next
> > Emacs tarball with Texinfo 4.
>
> I don't mind to use Texinfo 4, if there are no objections. It
> would solve the problem that matters to me.
But not the problem that matters to the OP and other users in a
similar situation.
The OP uses Debian and emacs-snapshot. From the original report
(to me, but same OP):
----
I use debian linux and I have emacs23, emacs24 andd emacs-snapsho
installed. They all come with their respective info files. The info
files from emacs23 and emacs24 use `' as delimiters, the info file
from emacs-snapshot uses ''.
While the info files from emacs23 and emacs24 were generated with
makeinfo 4.13, the one from emacs-snapshot was generated with
makeinfo 5.2. I don't know if this accounts for the difference.
ATM I building an emacs from development sources. I have makeinfo
version 5.2 installed. (...)
Aha the freshly built info file uses two straight single quotes,
as the ones shiped with emacs-snapshot.
The manual for makeinfo version 5.2 says:
'OUTPUT_ENCODING_NAME'
Normalized encoding name used for output files. Should be a usable
charset name in HTML, typically one of the preferred IANA encoding
names. By default, if an input encoding is set (typically through
'@documentencoding' or 'INPUT_ENCODING_NAME'), this information is
used to set the output encoding name. If no input encoding is
specified, the default output encoding name may be set by the
output format. In particular, the XML-based formats use 'utf-8'
for 'OUTPUT_ENCODING_NAME' if the encoding is not otherwise
specified. *Note @documentencoding::.
And tada: there is no @documentencoding directive in Emacs Lisp
Intros texinfo file.
----
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 20:31:01 GMT)
Full text and
rfc822 format available.
Message #153 received at 16292 <at> debbugs.gnu.org (full text, mbox):
>> Isn't there a way other than modifying the file to tell Texinfo that
>> the encoding is utf-8?
> No, not if you want makeinfo to put the 'coding' cookie in the file
> local variables section of the Info file it produces.
But that's OK: the `coding' cookie should also be unnecessary for utf-8.
> @documentencoding is the way.
> If so, we should at least fix the handful of manuals that already use
> "@documentencoding utf-8", or use non-ASCII characters without any
> @documentencoding, thus producing Info files that might display
> incorrectly in certain locales.
That's not a new problem and people haven't complained about it, AFAICT,
so I'd rather not touch it.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 20:33:01 GMT)
Full text and
rfc822 format available.
Message #156 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Plus, it's UTF-8 not Unicode.
No, I really meant Unicode: the issue is not lack of support for utf-8,
but lack of support for some Unicode chars.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 20:45:01 GMT)
Full text and
rfc822 format available.
Message #159 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 4 Jan 2014 12:24:05 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> > > Better would be to leave the files alone, and build the next
> > > Emacs tarball with Texinfo 4.
> >
> > I don't mind to use Texinfo 4, if there are no objections. It
> > would solve the problem that matters to me.
>
> But not the problem that matters to the OP and other users in a
> similar situation.
Yes, that too: Texinfo 4 still uses `..' for quoting.
> The OP uses Debian and emacs-snapshot. From the original report
> (to me, but same OP):
Again, this isn't an Emacs problem. It is wrong to expect Emacs to
fix problems caused by decisions of other packages. However, patches
are welcome to fix that separately by using, e.g., display tables.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 20:46:01 GMT)
Full text and
rfc822 format available.
Message #162 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: eggert <at> cs.ucla.edu, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
> Date: Sat, 04 Jan 2014 15:30:10 -0500
>
> >> Isn't there a way other than modifying the file to tell Texinfo that
> >> the encoding is utf-8?
> > No, not if you want makeinfo to put the 'coding' cookie in the file
> > local variables section of the Info file it produces.
>
> But that's OK: the `coding' cookie should also be unnecessary for utf-8.
I wouldn't rely on that, but I see your point.
> > If so, we should at least fix the handful of manuals that already use
> > "@documentencoding utf-8", or use non-ASCII characters without any
> > @documentencoding, thus producing Info files that might display
> > incorrectly in certain locales.
>
> That's not a new problem and people haven't complained about it, AFAICT,
> so I'd rather not touch it.
I won't recommend that: the effect is only visible with Texinfo 5,
which is still new. Complaints might come too late for us to be able
to fix them (after the release).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 20:54:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Complaints might come too late for us to be able
> to fix them (after the release).
Any such complaints would come only from people
expert enough to run makeinfo themselves, no?
So these people could be asked to run Texinfo 4,
just as we did, if they want to have quotes
`like this' that follow the older style. It's
not unreasonable to ask experts to run old programs
if they want to generate old-style output.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 20:54:02 GMT)
Full text and
rfc822 format available.
Message #168 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> Date: Sat, 04 Jan 2014 09:50:21 -0800
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>>
>> Defaulting to ASCII in all platforms would leave the original
>> bug unfixed by default on all installations, causing the
>> regression from `foo' to 'foo' that Drew Adams complained of.
>
> That's not an Emacs problem. The Texinfo developers decided to make
> that change, and they followed the GNU Coding Standards. Emacs needs
> to adapt, as the rest of the GNU project did. If you think this is a
> step backwards
Defaulting to ASCII in all platforms would not be not a Texinfo problem,
as the ASCII transformation in the proposed patch is an Emacs-only hack.
No other package uses it, or is likely to. Texinfo has an established
method to avoid the regression, namely to use UTF-8 quote symbols, and
Emacs could easily adopt this method, just as other GNU programs have.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 21:08:01 GMT)
Full text and
rfc822 format available.
Message #171 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> > > > Better would be to leave the files alone, and build the next
> > > > Emacs tarball with Texinfo 4.
> > >
> > > I don't mind to use Texinfo 4, if there are no objections. It
> > > would solve the problem that matters to me.
> >
> > But not the problem that matters to the OP and other users in a
> > similar situation.
>
> Yes, that too: Texinfo 4 still uses `..' for quoting.
No. The OP's problem came from an Emacs that was built otherwise.
That's the point. He was aware of that being the cause; it is
exactly that problem that he reported (to me).
Yes, Texinfo and makeinfo are not Emacs. That's your point. But
that does not solve the OP's problem. That's the point.
> > The OP uses Debian and emacs-snapshot.
>
> Again, this isn't an Emacs problem. It is wrong to expect Emacs
> to fix problems caused by decisions of other packages.
I can sympathize with that, and I agree with it generally. Still,
it seems that in this case it means that more and more Emacs users
will get worse Info behavior in Emacs, as more and more builders
move to a more recent Texinfo/makeinfo. Can we only tell users
that this is not an Emacs problem? That's the answer?
Perhaps there comes a point when it might make sense to work
around some problems that are strictly speaking "not an Emacs
problem". They can end up becoming a problem for Emacs (Emacs
users), whether or not Emacs is the source of the problem.
Of course, whether to try to work around such a problem probably
also depends on the difficulty of implementing (and maintaining)
the workaround. I cannot speak to that.
I will only say that it's too bad if Emacs users lose reasonable
Info behavior that they have enjoyed since the beginning.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 21:09:02 GMT)
Full text and
rfc822 format available.
Message #174 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Jan 2014 12:53:06 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
> > Complaints might come too late for us to be able
> > to fix them (after the release).
>
> Any such complaints would come only from people
> expert enough to run makeinfo themselves, no?
Not necessarily. I'm talking again about the Unicode characters
produced by Texinfo 5 when @documentencoding says utf-8. Any user can
bump into this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 21:11:03 GMT)
Full text and
rfc822 format available.
Message #177 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Jan 2014 12:53:26 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
> >> Date: Sat, 04 Jan 2014 09:50:21 -0800
> >> From: Paul Eggert <eggert <at> cs.ucla.edu>
> >>
> >> Defaulting to ASCII in all platforms would leave the original
> >> bug unfixed by default on all installations, causing the
> >> regression from `foo' to 'foo' that Drew Adams complained of.
> >
> > That's not an Emacs problem. The Texinfo developers decided to make
> > that change, and they followed the GNU Coding Standards. Emacs needs
> > to adapt, as the rest of the GNU project did. If you think this is a
> > step backwards
>
> Defaulting to ASCII in all platforms would not be not a Texinfo problem,
> as the ASCII transformation in the proposed patch is an Emacs-only hack.
I wasn't talking about ASCII transformation. I was talking about
either avoiding the use of "@documentencoding utf-8" or using
"--disable-encoding" for those manuals that need non-ASCII text.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 21:12:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> I won't recommend that: the effect is only visible with Texinfo 5,
> which is still new. Complaints might come too late for us to be able
> to fix them (after the release).
I think we should take the risk. It will also give us a good idea of
whether avoiding Unicode quotes is worth the trouble
of --disable-encoding (or of a sed script to convert them back to
ASCII).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 23:06:01 GMT)
Full text and
rfc822 format available.
Message #183 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Can we only tell users that this is not an Emacs problem?
Yes. The bug should be reported to Texinfo maintainers.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 23:30:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Not necessarily. I'm talking again about the Unicode characters
> produced by Texinfo 5 when @documentencoding says utf-8. Any user can
> bump into this.
A user won't bump into that in the released Emacs manual, if
we build it with Texinfo 4. The only people who will bump
into that are people who edit the manual and run Texinfo themselves.
These are few enough and expert enough that we can simply ask
them to use Texinfo 4 if they care about the quoting and don't
want to work on the trunk.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 23:36:02 GMT)
Full text and
rfc822 format available.
Message #189 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> I wasn't talking about ASCII transformation.
But I was, in the message you replied to.
My message was talking about whether the proposed patch
should default to the ASCII transformation. Doing that
would leave the original Emacs bug unfixed by default,
which is undesirable.
> I was talking about
> either avoiding the use of "@documentencoding utf-8" or using
> "--disable-encoding" for those manuals that need non-ASCII text.
Ah, OK, but neither of those approaches is suitable
for the Emacs manuals in the long run, after the
feature freeze is over. And in the short run we
can just leave the files alone, and build the
next release tarball with Texinfo 4.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 04 Jan 2014 23:46:01 GMT)
Full text and
rfc822 format available.
Message #192 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Drew Adams wrote:
> it seems that in this case it means that more and more Emacs users
> will get worse Info behavior in Emacs, as more and more builders
> move to a more recent Texinfo/makeinfo.
It's temporary, because we're in a feature freeze and don't
want to install the necessary feature until after the next release.
The next release should use Texinfo 4 to build the tarball, so
its info files should still use quotes `like this', and there
shouldn't be a regression.
After the feature freeze is over, we can install the necessary
feature and switch to the new Texinfo, which quotes ‘like this’,
so there still won't be a regression. The new feature will let
installers choose to quote 'like this' if they like (which
*will* be a regression from your point of view), but that'll
be an option that you won't have to choose.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 03:43:02 GMT)
Full text and
rfc822 format available.
Message #195 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 4 Jan 2014 13:07:15 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: eggert <at> cs.ucla.edu, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> > Yes, that too: Texinfo 4 still uses `..' for quoting.
>
> No. The OP's problem came from an Emacs that was built otherwise.
> That's the point. He was aware of that being the cause; it is
> exactly that problem that he reported (to me).
>
> Yes, Texinfo and makeinfo are not Emacs. That's your point. But
> that does not solve the OP's problem. That's the point.
It will solve some of the problem, because Emacs will be released with
the quoting he wanted.
But the problem itself should find there solution either in Texinfo,
or in the Lisp programs (and users' minds) that will adapt to the
change.
> I can sympathize with that, and I agree with it generally. Still,
> it seems that in this case it means that more and more Emacs users
> will get worse Info behavior in Emacs, as more and more builders
> move to a more recent Texinfo/makeinfo. Can we only tell users
> that this is not an Emacs problem? That's the answer?
As I said, patches are welcome to display '..' as something more
visually pleasing.
> I will only say that it's too bad if Emacs users lose reasonable
> Info behavior that they have enjoyed since the beginning.
That ship sailed several months ago. There's nothing we can do to
return it, unless Texinfo changes back (unlikely, if you ask me).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 03:44:01 GMT)
Full text and
rfc822 format available.
Message #198 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: eggert <at> cs.ucla.edu, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
> Date: Sat, 04 Jan 2014 16:11:36 -0500
>
> > I won't recommend that: the effect is only visible with Texinfo 5,
> > which is still new. Complaints might come too late for us to be able
> > to fix them (after the release).
>
> I think we should take the risk.
Why? what damage you envision from fixing a couple of manuals that are
affected by this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 03:49:01 GMT)
Full text and
rfc822 format available.
Message #201 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Jan 2014 15:29:24 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
> > Not necessarily. I'm talking again about the Unicode characters
> > produced by Texinfo 5 when @documentencoding says utf-8. Any user can
> > bump into this.
>
> A user won't bump into that in the released Emacs manual, if
> we build it with Texinfo 4. The only people who will bump
> into that are people who edit the manual and run Texinfo themselves.
> These are few enough and expert enough that we can simply ask
> them to use Texinfo 4 if they care about the quoting and don't
> want to work on the trunk.
There's no expertise involved in "make info". And it uses the version
of Texinfo installed on the system, which normally has nothing to do
with Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 03:50:02 GMT)
Full text and
rfc822 format available.
Message #204 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Jan 2014 15:35:36 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> > I was talking about
> > either avoiding the use of "@documentencoding utf-8" or using
> > "--disable-encoding" for those manuals that need non-ASCII text.
>
> Ah, OK, but neither of those approaches is suitable
> for the Emacs manuals in the long run, after the
> feature freeze is over. And in the short run we
> can just leave the files alone, and build the
> next release tarball with Texinfo 4.
My suggestion solves more potential problems, so I think it is better
even in the short run, if not in the long.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 04:56:01 GMT)
Full text and
rfc822 format available.
Message #207 received at 16292 <at> debbugs.gnu.org (full text, mbox):
>> > I won't recommend that: the effect is only visible with Texinfo 5,
>> > which is still new. Complaints might come too late for us to be able
>> > to fix them (after the release).
>> I think we should take the risk.
> Why? what damage you envision from fixing a couple of manuals that are
> affected by this?
The text you elided explains the benefit I hope to get from not changing
(you call it "fixing" but I disagree with this designation)
those manuals.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 05:24:01 GMT)
Full text and
rfc822 format available.
Message #210 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> There's no expertise involved in "make info".
Typical Emacs users don't run 'make info'.
And even for the few who do run it, it does nothing
unless they also edit a .texi file, which is
something typical users also are unlikely to
do. The rare user who's expert enough to edit
the manual, run 'make info', and care about
how the resulting quotes look, should be able
to understand and act on suggestions either to use
Texinfo 4 or to update to the post-freeze trunk.
> My suggestion solves more potential problems
I'm afraid not. Avoiding @documentencoding causes
Texinfo 5 to mishandle UTF-8 characters when generating
formats such as HTML, so that's a non-starter.
And both it and --disable-encoding cause the
regression that Drew noted. So it'd be unwise
to use either approach postfreeze when we build the
tarball's Info files with Texinfo 5 -- and these are
the most commonly-used Info files.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 06:14:02 GMT)
Full text and
rfc822 format available.
Message #213 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> It's temporary, because we're in a feature freeze and don't
> want to install the necessary feature until after the next release.
> The next release should use Texinfo 4 to build the tarball, so
> its info files should still use quotes `like this', and there
> shouldn't be a regression.
>
> After the feature freeze is over, we can install the necessary
> feature and switch to the new Texinfo, which quotes ‘like this’,
> so there still won't be a regression. The new feature will let
> installers choose to quote 'like this' if they like (which
> *will* be a regression from your point of view), but that'll
> be an option that you won't have to choose.
Sounds reasonable to me, though I guess it means that some users
whose installers choose '...' for them will see a regression wrt
1985 (presumably from anyone's point of view).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 16:20:02 GMT)
Full text and
rfc822 format available.
Message #216 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: eggert <at> cs.ucla.edu, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
> Date: Sat, 04 Jan 2014 23:55:51 -0500
>
> >> > I won't recommend that: the effect is only visible with Texinfo 5,
> >> > which is still new. Complaints might come too late for us to be able
> >> > to fix them (after the release).
> >> I think we should take the risk.
> > Why? what damage you envision from fixing a couple of manuals that are
> > affected by this?
>
> The text you elided explains the benefit I hope to get from not changing
I elided it because it started with "also", which I interpreted to
mean that the part I quoted stood on its own. So I asked for the
reasons to that part, and that part only.
If now you are saying that the reason is this:
> It will give us a good idea of whether avoiding Unicode quotes is
> worth the trouble of --disable-encoding (or of a sed script to
> convert them back to ASCII)
then I confess that it's a strange reason: why avoid solving a clear
problem just to know whether it is worth solving, when the solution is
at hand and quite simple.
> (you call it "fixing" but I disagree with this designation)
Let me try to convince you. Try this:
$ LC_CTYPE=sv_SE.ISO8859-1 ./src/emacs -Q
C-u C-h i info/htmlfontify.info RET
g Interactive RET
Then look around the middle of the first screen, in a paragraph that
begins with "You should", and tell me whether you still think this
need not be fixed. Also, note the encoding displayed by Emacs on the
mode line (it should be UTF-8).
Similar problems exist in org.info, mh-e.info, ses.info, and
dbus.info.
(You may need to generate the manuals with makeinfo 4.13 to see these
problems.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 16:31:02 GMT)
Full text and
rfc822 format available.
Message #219 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Jan 2014 21:23:03 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
> > There's no expertise involved in "make info".
>
> Typical Emacs users don't run 'make info'.
They might, if they want to make small changes.
In any case, as I show in my previous message, the problems are not
limited to Texinfo 5 (unlike what I previously thought).
> > My suggestion solves more potential problems
>
> I'm afraid not. Avoiding @documentencoding causes
> Texinfo 5 to mishandle UTF-8 characters when generating
> formats such as HTML, so that's a non-starter.
I didn't propose to make any changes in the HTML targets, they can
continue using --enable-encoding. I also didn't suggest to remove
@documentencoding; quite the contrary, the fix I suggested is to _add_
such a directive to those manuals that don't have it, but use UTF-8
encoded characters.
> And both it and --disable-encoding cause the
> regression that Drew noted.
That's not an Emacs problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 20:03:02 GMT)
Full text and
rfc822 format available.
Message #222 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Try this:
>
> $ LC_CTYPE=sv_SE.ISO8859-1 ./src/emacs -Q
> C-u C-h i info/htmlfontify.info RET
> g Interactive RET
That's a longstanding problem. For example,
if I run this in an Emacs-24.3 source tree:
$ LC_ALL=sv_SE.ISO8859-1 ./src/emacs -Q
C-u C-h i info/dbus.info RET
g Type Conversion RET M->
I see a "ÿ" that should be a "ÿ".
As I understand it this problem doesn't occur often,
and is limited to the now-rare users who employ
unibyte locales. If so, it's not urgent to fix this
longstanding problem now.
The problem is fixed by the proposed post-feature-freeze
patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 20:08:01 GMT)
Full text and
rfc822 format available.
Message #225 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 05 Jan 2014 12:02:48 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
> > Try this:
> >
> > $ LC_CTYPE=sv_SE.ISO8859-1 ./src/emacs -Q
> > C-u C-h i info/htmlfontify.info RET
> > g Interactive RET
>
> That's a longstanding problem. For example,
> if I run this in an Emacs-24.3 source tree:
>
> $ LC_ALL=sv_SE.ISO8859-1 ./src/emacs -Q
> C-u C-h i info/dbus.info RET
> g Type Conversion RET M->
>
> I see a "ÿ" that should be a "ÿ".
>
> As I understand it this problem doesn't occur often,
> and is limited to the now-rare users who employ
> unibyte locales. If so, it's not urgent to fix this
> longstanding problem now.
But the fix (for the next release) is easy and safe: just add an
appropriate @documentencoding. So I don't see why we should avoid
fixing this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 20:13:02 GMT)
Full text and
rfc822 format available.
Message #228 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> But the fix (for the next release) is easy and safe: just add an
> appropriate @documentencoding. So I don't see why we should avoid
> fixing this.
Then I'm puzzled, because when I did pretty much just that in
trunk bzr 115807, you reverted the patch. It's fine with me
if we reinstall that patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 20:20:01 GMT)
Full text and
rfc822 format available.
Message #231 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 05 Jan 2014 12:12:47 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
> > But the fix (for the next release) is easy and safe: just add an
> > appropriate @documentencoding. So I don't see why we should avoid
> > fixing this.
>
> Then I'm puzzled, because when I did pretty much just that in
> trunk bzr 115807, you reverted the patch. It's fine with me
> if we reinstall that patch.
If we are going to use Texinfo 4 for generating the manuals in the
next release, the problem that bothered me will not happen in the Info
files that will be in the release tarball.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sun, 05 Jan 2014 23:06:02 GMT)
Full text and
rfc822 format available.
Message #234 received at 16292 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii wrote:
> If we are going to use Texinfo 4 for generating the manuals in the
> next release, the problem that bothered me will not happen in the Info
> files that will be in the release tarball.
Ah, OK, then we can separate the proposed patch into two parts.
The first just adds @documentencoding lines, and can be installed
now. The second deals with ASCIIfying the info files, a new feature
that can wait until after the feature freeze is over. I'm attaching
both patches.
[document-encoding.diff (text/x-patch, attachment)]
[ascii-info-marks.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 06 Jan 2014 03:55:01 GMT)
Full text and
rfc822 format available.
Message #237 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 05 Jan 2014 15:05:33 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
>
> [1:text/plain Hide]
>
> Eli Zaretskii wrote:
> > If we are going to use Texinfo 4 for generating the manuals in the
> > next release, the problem that bothered me will not happen in the Info
> > files that will be in the release tarball.
>
> Ah, OK, then we can separate the proposed patch into two parts.
> The first just adds @documentencoding lines, and can be installed
> now. The second deals with ASCIIfying the info files, a new feature
> that can wait until after the feature freeze is over. I'm attaching
> both patches.
I'm okay with the first one.
As for the second, I still think that (a) the ASCII version should be
the default, and (b) using --enable/disable-encoding on the makeinfo
command line is an easier way of achieving the same effect. But if
Stefan prefers this method, so be it.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 06 Jan 2014 04:40:01 GMT)
Full text and
rfc822 format available.
Message #240 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> As for the second, I still think that (a) the ASCII version should be
> the default, and (b) using --enable/disable-encoding on the makeinfo
> command line is an easier way of achieving the same effect. But if
> Stefan prefers this method, so be it.
At this point, I prefer to let you guys decide,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 06 Jan 2014 05:32:01 GMT)
Full text and
rfc822 format available.
Message #243 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> I'm okay with the first one.
OK, I pushed it into the trunk as bzr 115884.
The second one should wait until after the feature freeze is over
so there's no rush in nailing down the details.
> As for the second, I still think that (a) the ASCII version should be
> the default, and (b) using --enable/disable-encoding on the makeinfo
> command line is an easier way of achieving the same effect.
Let's look at (b) first. I don't see how it would work,
since we can't assume that the installer has makeinfo,
which means the option cannot be made at install time
by using --enable-encoding or --disable-encoding.
Unless you want to ship two copies of each .info file
in the tarball, a full version and an ASCIIfied version?
That would work, but it's unnecessary
bloat of the tarball, since the ASCIIfied version can be
derived from the full version, and even aside from the bloat
the overall procedure is probably more complicated
than what we have already in the proposed patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Mon, 06 Jan 2014 16:16:02 GMT)
Full text and
rfc822 format available.
Message #246 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 05 Jan 2014 21:31:37 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> Eli Zaretskii wrote:
>
> > I'm okay with the first one.
>
> OK, I pushed it into the trunk as bzr 115884.
Thanks.
> The second one should wait until after the feature freeze is over
> so there's no rush in nailing down the details.
Right.
> > As for the second, I still think that (a) the ASCII version should be
> > the default, and (b) using --enable/disable-encoding on the makeinfo
> > command line is an easier way of achieving the same effect.
>
> Let's look at (b) first. I don't see how it would work,
> since we can't assume that the installer has makeinfo,
> which means the option cannot be made at install time
> by using --enable-encoding or --disable-encoding.
Is it a frequent situation that someone who does the configure and
"make" steps doesn't have makeinfo? I thought this to be rare. If
I'm wrong, then I guess those users who do want to generate the Info
files with a non-default style of punctuation will have to install
Texinfo or live with this minor problem. And if we use (a) as well,
then the distributed version will already be completely readable, if
not the most beautiful one.
> Unless you want to ship two copies of each .info file
> in the tarball, a full version and an ASCIIfied version?
No, of course not.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Tue, 07 Jan 2014 01:16:02 GMT)
Full text and
rfc822 format available.
Message #249 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Is it a frequent situation that someone who does the configure and
> "make" steps doesn't have makeinfo? I thought this to be rare.
It's reasonably common. In Debian, for example, texinfo is not
one of the essential packages. On many non-GNU environments such
as AIX and HP-UX, 'makeinfo' is not available unless you build and
install it yourself. And for the GNU project, 'makeinfo' isn't
listed as one of the standard utilities that Makefiles can assume:
http://www.gnu.org/prep/standards/standards.html#Utilities-in-Makefiles
> If I'm wrong, then I guess those users who do want to generate the Info
> files with a non-default style of punctuation will have to install
> Texinfo or live with this minor problem.
If the the installer could obtain some compensating advantage by
being forced to install 'makeinfo' to get the style they prefer,
it might be worth the hassle. But there doesn't seem to be any
such advantage. So why not use 'sed'? It avoids the hassle entirely.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Tue, 07 Jan 2014 03:57:01 GMT)
Full text and
rfc822 format available.
Message #252 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 06 Jan 2014 17:15:03 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> So why not use 'sed'?
It just feels unclean.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 18:12:01 GMT)
Full text and
rfc822 format available.
Message #255 received at 16292 <at> debbugs.gnu.org (full text, mbox):
I don't see a change from `...' to '...' in this recent build:
In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
of 2014-04-29 on ODIEONE
Bzr revision: 117031 monnier <at> iro.umontreal.ca-20140429151607-qnkgbymwfaj5ut08
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/Devel/emacs/snapshot/trunk
--enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
-Ic:/Devel/emacs/include''
But I've had a report from an info+.el user that his 24.4.50.1
build breaks the Info+ highlighting of names because '...' is
used now instead of `...'. Dunno whether he has control over
the generation of Info files from Texinfo.
AFAIK, there is no way, from Emacs Lisp, to know whether an Info
file has been built to use '...' or `...'. Is that correct?
IIUC, at Info build time there is a setting, @documentencoding,
that determines this. In any case, Texinfo must somehow know
which pattern is being used for Info.
Request: Could we please have this information transmitted to
the resulting Info files somehow, so that it could be obtained
by Lisp code?
It would be much better, for instance, for the info+.el code
to use one or the other pattern for highlighting than it would
be to try to highlight both in the same file, just to catch the
appropriate one.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 18:23:02 GMT)
Full text and
rfc822 format available.
Message #258 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 2 May 2014 11:11:40 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> I don't see a change from `...' to '...' in this recent build:
>
> In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
> of 2014-04-29 on ODIEONE
> Bzr revision: 117031 monnier <at> iro.umontreal.ca-20140429151607-qnkgbymwfaj5ut08
> Windowing system distributor `Microsoft Corp.', version 6.1.7601
> Configured using:
> `configure --prefix=/c/Devel/emacs/snapshot/trunk
> --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
> LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
> -Ic:/Devel/emacs/include''
>
> But I've had a report from an info+.el user that his 24.4.50.1
> build breaks the Info+ highlighting of names because '...' is
> used now instead of `...'. Dunno whether he has control over
> the generation of Info files from Texinfo.
This depends not only on the Texinfo sources of the docs, but also on
the version of makeinfo used by whoever produced the Info files as
part of the Emacs build. It is quite possible that the latter part is
different between your build and that other user's.
> AFAIK, there is no way, from Emacs Lisp, to know whether an Info
> file has been built to use '...' or `...'. Is that correct?
Why not? they are just characters.
> IIUC, at Info build time there is a setting, @documentencoding,
> that determines this.
No, these are ASCII characters, so @documentencoding has nothing to do
with it. But the version of makeinfo does: the latest versions
produce '...'.
> Request: Could we please have this information transmitted to
> the resulting Info files somehow, so that it could be obtained
> by Lisp code?
It is already there:
This is ../../info/emacs.info, produced by makeinfo version 4.13
from ./emacs.texi.
If the version is 5.x, then you should expect '...'.
Note that you could also have Unicode characters there. It's a mess.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 19:08:02 GMT)
Full text and
rfc822 format available.
Message #261 received at 16292 <at> debbugs.gnu.org (full text, mbox):
On 05/02/2014 11:11 AM, Drew Adams wrote:
> I've had a report from an info+.el user that his 24.4.50.1
> build breaks the Info+ highlighting of names because '...' is
> used now instead of `...'.
Emacs should be built either with an old makeinfo, which should quote
`like this' with ASCII accent-grave and apostrophe, or with a new
makeinfo, which should quote ‘like this’ with Unicode directed
single-quotes. Makeinfo shouldn't quote 'like this' with ASCII
apostrophe only. Perhaps your info+.el user could investigate why
makeinfo is misbehaving for them, and if they figure that out it might
be nice for us to modify the Emacs distribution to stop the misbehavior.
This should fix the problem without info+.el having to worry about which
makeinfo version was used.
Also: in a standard Emacs tarball the builder shouldn't ever run
makeinfo, as the info files should all be prebuilt and up-to-date. Can
your info+.el user please also investigate why that didn't work for them?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 19:20:01 GMT)
Full text and
rfc822 format available.
Message #264 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
>> I've had a report from an info+.el user that his 24.4.50.1
^^^^^^^^
[...]
> Also: in a standard Emacs tarball the builder shouldn't ever run
> makeinfo, as the info files should all be prebuilt and up-to-date. Can
> your info+.el user please also investigate why that didn't work for
> them?
There are no 24.4.50 tarballs, so I see nothing to investigate there.
It was presumably a build from bzr.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 19:21:01 GMT)
Full text and
rfc822 format available.
Message #267 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> > AFAIK, there is no way, from Emacs Lisp, to know whether an Info
> > file has been built to use '...' or `...'. Is that correct?
>
> Why not? they are just characters.
Huh? Yes, they are characters. And how would you determine
whether '...' or `...' quoting of names is in effect in a given
Info buffer?
You might be able to check whether, say, the Emacs manual has
'...' or `...' by moving to a particular node where you expect
a particular symbol to be quoted (and that you expect to remain
present across Emacs versions), and move to that symbol and test
the char before it... But that would be an ugly and inefficient
workaround, and different manuals might be built using different
makeinfo versions etc.
I'm asking for a simple check. Maybe a file-local variable or
something.
> > IIUC, at Info build time there is a setting, @documentencoding,
> > that determines this.
>
> No, these are ASCII characters, so @documentencoding has nothing
> to do with it. But the version of makeinfo does: the latest
> versions produce '...'.
I thought, from this thread, that builds could control whether
'...' or `...' gets used. Is that not the case? And I
(mistakenly) thought that @documentencoding was involved with that.
If '...' is used systematically from now on, starting with some
version of makeinfo, then that is indeed bad news.
'...' is absolutely inferior to `...', IMHO.
> > Request: Could we please have this information transmitted to
> > the resulting Info files somehow, so that it could be obtained
> > by Lisp code?
>
> It is already there:
> This is ../../info/emacs.info, produced by makeinfo version 4.13
> from ./emacs.texi.
> If the version is 5.x, then you should expect '...'.
Yes, at the beginning of the file, outside of what is visible
in the manual, i.e., in Info mode.
I want something simple, evaluable from Info mode. I don't want
to have to widen the buffer or change the mode or jump through
any other hoops. A function or a variable whose value lets
Lisp code know whether `...' or '...' quoting is in effect.
> Note that you could also have Unicode characters there.
Where is "there"? How does that relate to this quoting?
Are you perhaps referring to a possible use of curly quotes
for such quoting? That would indeed be bad (from my point of
view).
> It's a mess.
Perhaps we agree, for once, though we might not agree about
what the mess is; dunno.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 19:29:02 GMT)
Full text and
rfc822 format available.
Message #270 received at 16292 <at> debbugs.gnu.org (full text, mbox):
On 05/02/2014 12:19 PM, Glenn Morris wrote:
> There are no 24.4.50 tarballs, so I see nothing to investigate there.
> It was presumably a build from bzr.
Ah, thanks, then presumably the makeinfo on the user's machine is part
of the problem, and it'd be helpful to know exactly which version it was.
I expect it'll be better to squash the bug at the source than to send
info+.el down the rabbit hole of trying to parse quoting 'like this'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 19:34:02 GMT)
Full text and
rfc822 format available.
Message #273 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> > I've had a report from an info+.el user that his 24.4.50.1
> > build breaks the Info+ highlighting of names because '...'
> > is used now instead of `...'.
>
> Emacs should be built either with an old makeinfo, which should
> quote `like this' with ASCII accent-grave and apostrophe, or
> with a new makeinfo, which should quote 'like this' with Unicode
> directed single-quotes. Makeinfo shouldn't quote 'like this'
> with ASCII apostrophe only.
I thought Eli was saying that it does just that: '...'.
What am I missing between what you two are saying about this?
> Perhaps your info+.el user could investigate why makeinfo is
> misbehaving for them,
Can you suggest how? What should he look for?
> and if they figure that out it might be nice for us to modify
> the Emacs distribution to stop the misbehavior.
I think this user might be willing to check, if we could tell
him how to do so.
> This should fix the problem without info+.el having to worry
> about which makeinfo version was used.
Great, but I would still want Info+ to be able to easily test,
using Lisp, which is being used in the current Info buffer:
`...' or '...'.
As I mentioned, it is a lot better to try to fontify just the
proper pattern, rather than to try to fontify both possibilities
at the same time, just in case.
Such highlighting is never failsafe anyway (it can be thrown off
by a solitary quote symbol etc.), and if a regexp tries to match
both patterns at the same time then that just increases the
likelihood of doing the wrong thing.
> Also: in a standard Emacs tarball the builder shouldn't ever run
> makeinfo, as the info files should all be prebuilt and up-to-date.
> Can your info+.el user please also investigate why that didn't
> work for them?
So you are saying that if he got Emacs from a "standard tarball"
then '...' is the fault of the builder of that standard tarball.
Which would be whom?
I can try to find out where he got the Info files. I don't
think he built them himself, but I have asked him and hope to
hear back.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 20:37:02 GMT)
Full text and
rfc822 format available.
Message #276 received at 16292 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/02/2014 12:33 PM, Drew Adams wrote:
> I thought Eli was saying that it does just that: '...'.
Your user is reporting that, so that's what Eli is diagnosing. The point
is that makeinfo shouldn't be doing that.
>> Perhaps your info+.el user could investigate why makeinfo is
>> misbehaving for them,
> Can you suggest how?
Run 'makeinfo' on the attached file t.texi and look at the quoting in
the output file t.info. It should use ASCII accent-grave and apostrophe
with old texinfo, and Unicode curly single quotes with new texinfo.
Similarly, the double quotes should use ASCII undirected double-quote
(both times) with old texinfo, and Unicode curly double quotes with new
texinfo.
> I would still want Info+ to be able to easily test, using Lisp, which
> is being used in the current Info buffer: `...' or '...'.
Info files should never use the latter in Emacs 24.4, so this shouldn't
be a problem.
Down the road there may be a problem, as we really need to accommodate
new Texinfo. It has been suggested that we change the Emacs build
procedure to transliterate the output of new Texinfo so that by default
it quotes 'like this' instead of ‘like this’. I think this would be a
mistake, and your recent bug report gives another argument against it.
For your planning purposes, here is a list of non-ASCII characters that
are generated by new Texinfo when applied to the Emacs documentation as
of January or so. You might want to check that info+.el handles these
characters, as some users will run into them either because they built
the manuals themselves with new Texinfo, or because they're reading
manuals generated by other GNU projects. I think Emacs is the only
holdout that still insists on old Texinfo.
' ' (i.e., NO-BREAK SPACE, U+00A0)
'真' (i.e., Han character 'real, actual, true, genuine', U+771F)
¤ © ¬ » À Å ß à á ä å ç è é ê ì í ï ò ó ö ø ü ć č ł ń ő Š š – — ‘ ’ “ ”
• … → ↦ ⇒ − ≡ ⊣ ★
[t.texi (text/x-texinfo, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 20:54:02 GMT)
Full text and
rfc822 format available.
Message #279 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> >> Perhaps your info+.el user could investigate why makeinfo is
> >> misbehaving for them,
> > Can you suggest how?
>
> Run 'makeinfo' on the attached file t.texi and look at the quoting in
> the output file t.info. It should use ASCII accent-grave and apostrophe
> with old texinfo, and Unicode curly single quotes with new texinfo.
> Similarly, the double quotes should use ASCII undirected double-quote
> (both times) with old texinfo, and Unicode curly double quotes with new
> texinfo.
OK, I just passed that information along to him.
FWIW, I have received this info from him:
I built from source with makinfo 5.2. However, makeinfo 5.2 works
fine for Emacs pretest (emacs 24.3.90), but not for Emacs trunk
(24.4.50): bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk
Here are the steps to build:
- ./configure --with-x-toolkit=gtk
- make
- sudo make install
What does old vs new texinfo refer to? Did you perhaps mean old vs
new makeinfo? If not, how does he tell whether he has "old" or "new"
Texinfo?
> > I would still want Info+ to be able to easily test, using Lisp, which
> > is being used in the current Info buffer: `...' or '...'.
>
> Info files should never use the latter in Emacs 24.4, so this shouldn't
> be a problem.
>
> Down the road there may be a problem, as we really need to accommodate
> new Texinfo. It has been suggested that we change the Emacs build
> procedure to transliterate the output of new Texinfo so that by default
> it quotes 'like this' instead of ‘like this’. I think this would be a
> mistake, and your recent bug report gives another argument against it.
Is the problem just for `...' vs '...' or ‘...’? What about Lisp (and
other) code, where we use ", ', and `, and none of those should be
changed to a curly version of the same? A Lisp string, for instance,
must be enclosed in straight double-quote chars, the same char at each
end.
It would be madness if such chars were being automatically "improved"
everywhere willy nilly to become curly versions.
> For your planning purposes, here is a list of non-ASCII characters that
> are generated by new Texinfo when applied to the Emacs documentation as
> of January or so. You might want to check that info+.el handles these
> characters, as some users will run into them either because they built
> the manuals themselves with new Texinfo, or because they're reading
> manuals generated by other GNU projects. I think Emacs is the only
> holdout that still insists on old Texinfo.
>
> ' ' (i.e., NO-BREAK SPACE, U+00A0)
> '真' (i.e., Han character 'real, actual, true, genuine', U+771F)
>
> ¤ © ¬ » À Å ß à á ä å ç è é ê ì í ï ò ó ö ø ü ć č ł ń ő Š š – — ‘ ’ “ ”
> • … → ↦ ⇒ − ≡ ⊣ ★
Not sure why you let me know this (but I'm glad to have it). A priori,
I have no problem with any such chars in an Info buffer. Any problems
that I would have would I think come from substituting chars that
currently have particular meaning to Info (or to Lisp etc. - see above).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 21:09:01 GMT)
Full text and
rfc822 format available.
Message #282 received at 16292 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi I am the user in discussion,
The output is in the attached file. Probably the Emacs pretest got
pre-compiled info documents?
Some relevant information:
- Output from *makeinfo --version*:
makeinfo (GNU texinfo) 5.2
>
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
- Which *makeinfo* I am using:
/usr/bin/makeinfo
>
- The other two config.log files for each Emacs version, both use
*/usr/bin/makeinfo*
I also installed texinfo 5.1 and the result is the same.
OS:
No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 14.04 LTS
> Release: 14.04
> Codename: trusty
>
Thanks,
Tu.
On Sat, May 3, 2014 at 3:45 AM, Drew Adams <drew.adams <at> oracle.com> wrote:
> Hi again,
>
>
>
> Thanks for that info - I've passed it along to the bug thread.
>
>
>
> From the bug thread there is this request from you. Could you check this?
>
>
>
> > Run 'makeinfo' on the attached file t.texi and look at the quoting in
>
> > the output file t.info. It should use ASCII accent-grave and apostrophe
>
> > with old texinfo, and Unicode curly single quotes with new texinfo.
>
> > Similarly, the double quotes should use ASCII undirected double-quote
>
> > (both times) with old texinfo, and Unicode curly double quotes with new
>
> > texinfo.
>
>
>
> Thx - Drew
>
>
>
> I built from source with makinfo 5.2. However, makeinfo 5.2 works fine for
> Emacs pretest (emacs 24.3.90), but not for Emacs trunk(24.4.50):
>
> bzr branch bzr://bzr.savannah.gnu.org/emacs/
>
> *trunk*
>
> Here are the steps to build:
>
> - ./configure --with-x-toolkit=gtk
>
> - make
>
> - sudo make install
>
[Message part 2 (text/html, inline)]
[t.info (application/x-info, attachment)]
[config.log.pretest (application/octet-stream, attachment)]
[config.log.trunk (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 21:11:01 GMT)
Full text and
rfc822 format available.
Message #285 received at 16292 <at> debbugs.gnu.org (full text, mbox):
PS also note that vhdl-mode.texi does not contain @documentencoding.
I think it's a bit crap if we are supposed to remember to add this to
all new texi files, even if they have no real need for it.
(Presumably the fabulous info+.el is supposed to handle other info files
besides just those from Emacs, so it needs to handle this anyway.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 21:12:02 GMT)
Full text and
rfc822 format available.
Message #288 received at 16292 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Please note that when I mean two config.log files use */usr/bin/makeinfo*,
I really mean the logs contains the path to the makeinfo I'm using.
On Sat, May 3, 2014 at 4:08 AM, Tu Do <tuhdo1710 <at> gmail.com> wrote:
> Hi I am the user in discussion,
>
> The output is in the attached file. Probably the Emacs pretest got
> pre-compiled info documents?
>
> Some relevant information:
>
> - Output from *makeinfo --version*:
>
> makeinfo (GNU texinfo) 5.2
>>
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>>
>
> - Which *makeinfo* I am using:
>
> /usr/bin/makeinfo
>>
>
> - The other two config.log files for each Emacs version, both use
> */usr/bin/makeinfo*
>
> I also installed texinfo 5.1 and the result is the same.
>
> OS:
>
> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description: Ubuntu 14.04 LTS
>> Release: 14.04
>> Codename: trusty
>>
>
>
> Thanks,
>
> Tu.
>
>
> On Sat, May 3, 2014 at 3:45 AM, Drew Adams <drew.adams <at> oracle.com> wrote:
>
>> Hi again,
>>
>>
>>
>> Thanks for that info - I've passed it along to the bug thread.
>>
>>
>>
>> From the bug thread there is this request from you. Could you check this?
>>
>>
>>
>> > Run 'makeinfo' on the attached file t.texi and look at the quoting in
>>
>> > the output file t.info. It should use ASCII accent-grave and apostrophe
>>
>> > with old texinfo, and Unicode curly single quotes with new texinfo.
>>
>> > Similarly, the double quotes should use ASCII undirected double-quote
>>
>> > (both times) with old texinfo, and Unicode curly double quotes with new
>>
>> > texinfo.
>>
>>
>>
>> Thx - Drew
>>
>>
>>
>> I built from source with makinfo 5.2. However, makeinfo 5.2 works fine
>> for Emacs pretest (emacs 24.3.90), but not for Emacs trunk(24.4.50):
>>
>> bzr branch bzr://bzr.savannah.gnu.org/emacs/
>>
>> *trunk*
>>
>> Here are the steps to build:
>>
>> - ./configure --with-x-toolkit=gtk
>>
>> - make
>>
>> - sudo make install
>>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 21:15:01 GMT)
Full text and
rfc822 format available.
Message #291 received at 16292 <at> debbugs.gnu.org (full text, mbox):
On 05/02/2014 01:53 PM, Drew Adams wrote:
> FWIW, I have received this info from him: I built from source with
> makinfo 5.2. However, makeinfo 5.2 works fine for Emacs pretest (emacs
> 24.3.90), but not for Emacs trunk (24.4.50): bzr branch
> bzr://bzr.savannah.gnu.org/emacs/trunk Here are the steps to build: -
> ./configure --with-x-toolkit=gtk - make - sudo make install
Works for me, with makeinfo 5.2. I see curly quotes in the info files
when I configure and build and install with that recipe. If it's
failing for him we need to know what the failure is and how to reproduce it.
> What does old vs new texinfo refer to? Did you perhaps mean old vs new
> makeinfo? If not, how does he tell whether he has "old" or "new" Texinfo?
'makeinfo --version'. The makeinfo command is part of the texinfo package.
> Is the problem just for `...' vs '...' or ‘...’?
Not sure what you mean by "the problem", but other characters are
affected, yes.
> What about Lisp (and other) code, where we use ", ', and `, and none
> of those should be changed to a curly version of the same?
Shouldn't be a problem, as those characters should not be changed.
Makeinfo can determine this from the markup in the .texi file.
> ' ' (i.e., NO-BREAK SPACE, U+00A0) '真' (i.e., Han character 'real,
> actual, true, genuine', U+771F) ¤ © ¬ » À Å ß à á ä å ç è é ê ì í ï ò
> ó ö ø ü ć č ł ń ő Š š – — ‘ ’ “ ” • … → ↦ ⇒ − ≡ ⊣ ★
> Not sure why you let me know this (but I'm glad to have it). A priori,
> I have no problem with any such chars in an Info buffer. Any problems
> that I would have would I think come from substituting chars that
> currently have particular meaning to Info (or to Lisp etc. - see above).
Some of those characters do have a particular meaning. For example, •
is used for bulleted lists instead of *, so if info+.el is keying only
off "*" (for old texinfo) it'll need to change to support new texinfo.
Other characters are used for output displays.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 21:26:01 GMT)
Full text and
rfc822 format available.
Message #294 received at 16292 <at> debbugs.gnu.org (full text, mbox):
On 05/02/2014 02:10 PM, Glenn Morris wrote:
> PS also note that vhdl-mode.texi does not contain @documentencoding.
> I think it's a bit crap if we are supposed to remember to add this to
> all new texi files, even if they have no real need for it.
It's just the top-level .texi files, but yes it's annoying. I think we
have a bug report in for that, for what it's worth.
I fixed the vhdl-mode.texi problem in Emacs trunk bzr 117045 and checked
that it was the only .texi file in the trunk with that problem.
> (Presumably the fabulous info+.el is supposed to handle other info files
> besides just those from Emacs, so it needs to handle this anyway.)
Yup.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 21:30:02 GMT)
Full text and
rfc822 format available.
Message #297 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> > > Down the road there may be a problem...
> > Is the problem just for `...' vs '...' or ‘...’?
>
> Not sure what you mean by "the problem", but other characters are
> affected, yes.
You're the one who said there may be a problem in the future... ;-)
For me, the problem is that what used to be represented as `...' could
be represented as something else - IIUC it could be `...', '...' or
‘...’.
> > What about Lisp (and other) code, where we use ", ', and `, and none
> > of those should be changed to a curly version of the same?
>
> Shouldn't be a problem, as those characters should not be changed.
> Makeinfo can determine this from the markup in the .texi file.
Good.
> > ' ' (i.e., NO-BREAK SPACE, U+00A0) '真' (i.e., Han character 'real,
> > actual, true, genuine', U+771F) ¤ © ¬ » À Å ß à á ä å ç è é ê ì í ï ò
> > ó ö ø ü ć č ł ń ő Š š – — ‘ ’ “ ” • … → ↦ ⇒ − ≡ ⊣ ★
> >
> > Not sure why you let me know this (but I'm glad to have it). A priori,
> > I have no problem with any such chars in an Info buffer. Any problems
> > that I would have would I think come from substituting chars that
> > currently have particular meaning to Info (or to Lisp etc. - see above).
>
> Some of those characters do have a particular meaning. For example, •
> is used for bulleted lists instead of *, so if info+.el is keying only
> off "*" (for old texinfo) it'll need to change to support new texinfo.
> Other characters are used for output displays.
I see. No, Info+ does nothing special with bullets. Well, it does the
same kind of thing that info.el does wrt bulleted menu items, e.g.:
(re-search-forward (concat "^\\* +" (regexp-quote nodename) "::") end t)
If info.el has to adjust for that then info+.el will do so similarly.
If not, not.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 21:40:01 GMT)
Full text and
rfc822 format available.
Message #300 received at 16292 <at> debbugs.gnu.org (full text, mbox):
OK, thanks, so it appears that you're using the new makeinfo, which is
doing the right thing by its lights, namely, it's using Unicode directed
curly quotes ‘like this’ and it is not using undirected ASCII quotes
'like this'.
If info+.el can't handle curly quotes, it needs to be fixed regardless
of what we do for Emacs info files, as other projects are using this
style already.
I understand that Drew would prefer some trivial way to do decide which
style to search for, but I don't see anything obvious. One possibility
would be to use curly quotes if the file contains curly quotes anywhere,
but that's not trivial. I suppose Drew could file a bug report with the
Texinfo folks and wait a few months, but there are lot of .info files
out in the wild already, so it looks like he may have to go with
something nontrivial.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Fri, 02 May 2014 21:49:02 GMT)
Full text and
rfc822 format available.
Message #303 received at 16292 <at> debbugs.gnu.org (full text, mbox):
On 05/02/2014 02:28 PM, Drew Adams wrote:
> I see. No, Info+ does nothing special with bullets. Well, it does the
> same kind of thing that info.el does wrt bulleted menu items
That shouldn't be a problem, since new Texinfo still uses "*" for
bulleted menu items. It's only things like "@itemize @bullet" that are
different.
Reply sent
to
Glenn Morris <rgm <at> gnu.org>:
You have taken responsibility.
(Sat, 03 May 2014 00:56:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Gregor Zattler <grfz <at> gmx.de>:
bug acknowledged by developer.
(Sat, 03 May 2014 00:56:03 GMT)
Full text and
rfc822 format available.
Message #308 received at 16292-done <at> debbugs.gnu.org (full text, mbox):
Version: 24.4
Gregor Zattler wrote:
> or the *.texi files should have @documentencoding directives which
> produce single curly quotes.
They now do so, so the reported issue is fixed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 03 May 2014 06:03:02 GMT)
Full text and
rfc822 format available.
Message #311 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 2 May 2014 12:33:33 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 16292 <at> debbugs.gnu.org, grfz <at> gmx.de
>
> > > I've had a report from an info+.el user that his 24.4.50.1
> > > build breaks the Info+ highlighting of names because '...'
> > > is used now instead of `...'.
> >
> > Emacs should be built either with an old makeinfo, which should
> > quote `like this' with ASCII accent-grave and apostrophe, or
> > with a new makeinfo, which should quote 'like this' with Unicode
> > directed single-quotes. Makeinfo shouldn't quote 'like this'
> > with ASCII apostrophe only.
>
> I thought Eli was saying that it does just that: '...'.
> What am I missing between what you two are saying about this?
@documentencoding, I think. It determines whether makeinfo 5.x will
use '...' or ‘...’.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 03 May 2014 06:58:02 GMT)
Full text and
rfc822 format available.
Message #314 received at 16292 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> @documentencoding, I think. It determines whether makeinfo 5.x will
> use '...' or ‘...’.
Yes, that might explain things. If a toplevel .texi file does not
contain @documentencoding, makeinfo 5 will quote 'like this'. Emacs
doesn't do this, though.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 03 May 2014 09:29:02 GMT)
Full text and
rfc822 format available.
Message #317 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> I want something simple, evaluable from Info mode.
(save-excursion
(save-restriction
(widen)
(goto-char (point-min))
(if (and (re-search-forward
"makeinfo[ \n]version[ \n]\\([0-9]+.[0-9]+\\)"
(line-beginning-position 4) t)
(version< (match-string 1) "5.0"))
'backquote
(if (string-match-p "utf-8" (symbol-name buffer-file-coding-system))
'curly-quote
'quote))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 03 May 2014 13:52:02 GMT)
Full text and
rfc822 format available.
Message #320 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> > I want something simple, evaluable from Info mode. I don't
> > want to have to widen the buffer or change the mode or jump
> > through any other hoops. A function or a variable whose value
> > lets Lisp code know whether `...' or '...' quoting is in effect.
>
> (save-excursion
> (save-restriction
> (widen)
> (goto-char (point-min))
> (if (and (re-search-forward
> "makeinfo[ \n]version[ \n]\\([0-9]+.[0-9]+\\)"
> (line-beginning-position 4) t)
> (version< (match-string 1) "5.0"))
> 'backquote
> (if (string-match-p "utf-8"
> (symbol-name buffer-file-coding-system))
> 'curly-quote
> 'quote))))
Thanks. I guess that's as good as it's going to get. I was hoping
for a file/buffer local variable or something. This is the kind of
hoop-jumping I was talking about, but I do appreciate your having
coded it up.
This would need to be consulted each time an Info node is fontified.
Yes, the search can be done instead just whenever the Info file is
changed, and then saved for consultation upon node fontifying for
the same file. (Still, I would hope for something simpler.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Sat, 03 May 2014 15:52:01 GMT)
Full text and
rfc822 format available.
Message #323 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> Thanks. I guess that's as good as it's going to get. I was hoping
> for a file/buffer local variable or something. This is the kind of
> hoop-jumping I was talking about, but I do appreciate your having
> coded it up.
>
> This would need to be consulted each time an Info node is fontified.
> Yes, the search can be done instead just whenever the Info file is
> changed, and then saved for consultation upon node fontifying for
> the same file. (Still, I would hope for something simpler.)
I still think that such a local variable would be useful for Emacs,
but FYI:
I updated info+.el without regard to checking whether Info uses
curly or straight quote-wrapping for this. It's not so clean as
searching only for the format that is actually used, but it seems
to be fine to just search for both. Dumb, but it works OK.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Wed, 07 May 2014 20:25:01 GMT)
Full text and
rfc822 format available.
Message #326 received at 16292 <at> debbugs.gnu.org (full text, mbox):
>> Thanks. I guess that's as good as it's going to get. I was hoping
>> for a file/buffer local variable or something. This is the kind of
>> hoop-jumping I was talking about, but I do appreciate your having
>> coded it up.
>>
>> This would need to be consulted each time an Info node is fontified.
>> Yes, the search can be done instead just whenever the Info file is
>> changed, and then saved for consultation upon node fontifying for
>> the same file. (Still, I would hope for something simpler.)
>
> I still think that such a local variable would be useful for Emacs,
What would be useful is a variable to hold the makeinfo version
extracted from the visited Info manual. Such variable could be used
to simplify feature checks like `Info-file-supports-index-cookies'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16292; Package
emacs.
(Wed, 07 May 2014 20:42:01 GMT)
Full text and
rfc822 format available.
Message #329 received at 16292 <at> debbugs.gnu.org (full text, mbox):
> >> Thanks. I guess that's as good as it's going to get. I was hoping
> >> for a file/buffer local variable or something. This is the kind of
> >> hoop-jumping I was talking about, but I do appreciate your having
> >> coded it up.
> >>
> >> This would need to be consulted each time an Info node is fontified.
> >> Yes, the search can be done instead just whenever the Info file is
> >> changed, and then saved for consultation upon node fontifying for
> >> the same file. (Still, I would hope for something simpler.)
> >
> > I still think that such a local variable would be useful for Emacs,
>
> What would be useful is a variable to hold the makeinfo version
> extracted from the visited Info manual. Such variable could be used
> to simplify feature checks like `Info-file-supports-index-cookies'.
That's what I had in mind - but I wasn't aware of that additional
use case.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 05 Jun 2014 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 335 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.