Re: Info pages opened with an incorrect coding system
In article [EMAIL PROTECTED], Eli Zaretskii [EMAIL PROTECTED] writes: Really, I think the only good way of solving this is to have a `coding:' tag in the Info file. Handa-san, do you agree? I have now installed a change to use @documentencoding and the --enable-encoding switch, so that the `coding:' tag is produced in info/emacs-mime. Please see if that solves the problem. Thank you Eli for working on this matter, I agree with your fix. And, I'm sorry for being late in reponding. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Eli Zaretskii [EMAIL PROTECTED] writes: [...] I have now installed a change to use @documentencoding and the --enable-encoding switch, so that the `coding:' tag is produced in info/emacs-mime. Please see if that solves the problem. No problem now, thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-pretest-bug@gnu.org From: Zhang Wei [EMAIL PROTECTED] Date: Sat, 14 Jul 2007 19:23:50 +0800 Eli Zaretskii [EMAIL PROTECTED] writes: [...] I have now installed a change to use @documentencoding and the --enable-encoding switch, so that the `coding:' tag is produced in info/emacs-mime. Please see if that solves the problem. No problem now, thanks. Thank you for testing this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Date: Sat, 07 Jul 2007 23:51:55 +0300 From: Eli Zaretskii [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED] That is why I asked what it is that makes chinese-iso-8bit the default on his system. His language environment is Chinese, so chinese-iso-8bit is high on the priority list of encodings when insert-file-contents detects the encoding of the manual. And detect_coding is not smart enough to distinguish between Latin-N and chinese-iso-8bit, so it returns the latter as the highest priority encoding that (it thinks) fits the bill. Really, I think the only good way of solving this is to have a `coding:' tag in the Info file. Handa-san, do you agree? I have now installed a change to use @documentencoding and the --enable-encoding switch, so that the `coding:' tag is produced in info/emacs-mime. Please see if that solves the problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Date: Mon, 9 Jul 2007 16:14:15 -0500 From: [EMAIL PROTECTED] (Karl Berry) Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED] source was written well, I can't agree that it is bad to use literal characters instead of Texinfo commands. Perhaps I'm confused: if Texinfo commands are not the recommended way, then why do we have them? why not tell users to always use literal non-ASCII characters? IOW, I think the fact that the document specifies @documentencoding should be enough for makeinfo to obey; relying on an additional command-line switch is unreliable. I don't see that it's unreliable, although I could agree with inconvenient. Sorry, I should have explained: it is unreliable from the point of view of the document author. As an author, I cannot simply put a @documentencoding directive in the document and be sure that the result will absolutely positively displayed correctly in Emacs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Perhaps I'm confused: if Texinfo commands are not the recommended way, The Texinfo commands aren't unrecommended either. Both ways have their advantages -- it depends on the document. That's why we support both. then why do we have them? why not tell users to always use literal non-ASCII characters? Because there are many, many cases where the document is 99+% English, representable in 7-bit ASCII, but a few special characters and/or accented letters are needed. It would be horrible to force users into the whole encoding madness just for that. On the other hand, for a whole document written in Polish or whatever, it is exceedingly painful to have to resort to the accent commands; it makes the source nearly unreadable. That's when having the 8-bit chars is useful. Things have been this way for decades. It's not going to change. Anyway, back to the suggestion at hand: fine, I will make the --enable-encoding behavior the default when @documentencoding is specified in the upcoming release. I hope it helps. karl ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Date: Tue, 10 Jul 2007 13:10:17 -0500 From: [EMAIL PROTECTED] (Karl Berry) Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Anyway, back to the suggestion at hand: fine, I will make the --enable-encoding behavior the default when @documentencoding is specified in the upcoming release. I hope it helps. Thanks, I think it will help a lot. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
From: Richard Stallman [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Date: Sun, 08 Jul 2007 18:23:28 -0400 It is pure luck if an Info file was generated for the same character set that your terminal supports. That's not what I see when I travel, especially not in the Far East. Personally, I think preferring locale-specific encoding is TRT, since most of the installed manuals that use non-ASCII characters are more likely to use that than anything else. No, they will use a whole range of coding systems, on your machine, on my machine, and on anybody's machine. That is not a solution. That is not a 100% solution for 100% of the problem, but it's a good compromise that works well in practice. You often advise others to shy away of purism and instead embrace practical compromises on the Right side of the 80-20 divide. Why not go with this advice in this case? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Date: Sun, 8 Jul 2007 17:56:12 -0500 From: [EMAIL PROTECTED] (Karl Berry) Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED] I could easily change things so that the Local Variables section was always output if a @documentencoding was present. I don't see any particular harm in that. I agree that it should be the default. Whether we should start to output 8-bit files by default for any input with a @documentencoding, I'm less sure. IMO, it's pretty much pointless to _not_ output non-ASCII characters, but still produce the Local Variables section, because without 8-bit characters the result is a plain ASCII file. That is, if the Texinfo source was written well, and used @-commands such as @'e instead of verbatim 8-bit characters. IOW, I think the fact that the document specifies @documentencoding should be enough for makeinfo to obey; relying on an additional command-line switch is unreliable. We could have --disable-encoding switch to turn off the default. but it might be better to generate all the Info files in UTF-8. Maybe, but it would be a lot of work. On the input side, makeinfo has no special understanding of what it's reading. If there are eight-bit bytes in the input file, it just outputs them as-is, which works well enough now; we couldn't get away with that any more. On the output side, this would mean converting from some arbitrary encoding system to UTF-8. Of course changing either of these is possible, but neither is easy. Wouldn't linking against libiconv solve all these with minimal fuss? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
That is not a 100% solution for 100% of the problem, but it's a good compromise that works well in practice. You often advise others to shy away of purism and instead embrace practical compromises on the Right side of the 80-20 divide. Why not go with this advice in this case? Because the 20% that fails will tend to include all the general-purpose software that is used around the world. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
I agree that it should be the default. Very well, I'll change that. but still produce the Local Variables section, because without 8-bit characters the result is a plain ASCII file. As you know, if the input uses 8-bit characters, the output will also use 8-bit characters, regardless of --enable-encoding. source was written well, I can't agree that it is bad to use literal characters instead of Texinfo commands. It makes for a far more readable source, among other things. IOW, I think the fact that the document specifies @documentencoding should be enough for makeinfo to obey; relying on an additional command-line switch is unreliable. I don't see that it's unreliable, although I could agree with inconvenient. I don't recall all the details of why we created --enable-encoding all those years ago. At this point, it does seem more useful to make it the default, so that any document with @documentencoding gets the output in that encoding, as best we can manage. Wouldn't linking against libiconv solve all these with minimal fuss? Sure, hopefully libiconv would be helpful, but I highly doubt the minimal fuss. I suspect it will mean essentially rewriting the entire program (not that that would be a bad thing, but ...), because it is changing the fundamental way in which characters are both read and written. If you want to delve into it, you're welcome to try. I rather doubt you have an excess of spare hacking time available either, though ... Karl ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
On the other hand, we might also want to fix a coding system for Info files, so that their handling will not depend on the locale. How? Do you mean to encode Info files in UTF-8 or some such? I mean, for some specific coding system. UTF-8 might be a good choice, but not necessarily the best. That would not work well with the stand-alone Info reader, which is a text-mode program and thus limited to the character set supported by the underlying text terminal. It is pure luck if an Info file was generated for the same character set that your terminal supports. Thus, we can't expect good results from the stand-alone Info reader unless it understands coding systems to some extent. But if we use the same coding system for all Info files, at least the stand-alone Info reader only needs to understand that one coding system. Personally, I think preferring locale-specific encoding is TRT, since most of the installed manuals that use non-ASCII characters are more likely to use that than anything else. No, they will use a whole range of coding systems, on your machine, on my machine, and on anybody's machine. That is not a solution. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
If I'm understanding correctly, it can already be done. If you use the @documentencoding command in the Texinfo source, and then specify --enable-encoding to makeinfo, the resulting Info file(s) will contain a Local Variables section setting the `coding' variable. What happens if you do not specify --enable-encoding? For instance, Local Variables: coding: iso-8859-2 End: This means different Info files will use different coding systems. That works fine in Emacs, which can read them all, but it might be better to generate all the Info files in UTF-8. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
What happens if you do not specify --enable-encoding? --enable-encoding principally affects two things. 1) whether the Local Variables section is output. 2) whether Texinfo constructs such @'e outputs an ASCII transliteration of the accented character (e'), or a real 8-bit accented character (assuming the given @documentencoding supports it). The reason for this is that there was general agreement that having makeinfo suddenly start outputting 8-bit files would be unwelcome. I could easily change things so that the Local Variables section was always output if a @documentencoding was present. I don't see any particular harm in that. Whether we should start to output 8-bit files by default for any input with a @documentencoding, I'm less sure. --enable-encoding was added in version 4.1, March 2002. That works fine in Emacs, which can read them all, I am sure that the vast majority of Info documents are read in Emacs. Worrying about Info documents being read in some other viewer doesn't seem very important to me. but it might be better to generate all the Info files in UTF-8. Maybe, but it would be a lot of work. On the input side, makeinfo has no special understanding of what it's reading. If there are eight-bit bytes in the input file, it just outputs them as-is, which works well enough now; we couldn't get away with that any more. On the output side, this would mean converting from some arbitrary encoding system to UTF-8. Of course changing either of these is possible, but neither is easy. It doesn't seem to me that the gain is worth the time. It's not like the support for ISO-8859-* is going to disappear. karl ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Richard, is it okay to assume Texinfo 4.6 for the CVS trunk? To support @documentencoding, when it appears in a .texi file, would not require anyone to move to Texinfo 4.6. There is no harm in supporting it, so let's do so. The problem is that that may not solve the whole problem. Even people who use Texinfo 4.6, many years from now, won't generally write @documentencoding in all their files. That is why I asked what it is that makes chinese-iso-8bit the default on his system. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
The default coding system is determined by Locale settings, that is `LC_ALL', `LC_CTYPE', or `LANG'. Thanks. I rechecked the first message and saw that the problem only affects a few Info files that use non-ASCII characters. Maybe changing those manuals to use @documentencoding is the right fix. On the other hand, we might also want to fix a coding system for Info files, so that their handling will not depend on the locale. Handa and Karl, what do you think? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
From: Richard Stallman [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Date: Sat, 07 Jul 2007 09:06:32 -0400 Richard, is it okay to assume Texinfo 4.6 for the CVS trunk? To support @documentencoding, when it appears in a .texi file, would not require anyone to move to Texinfo 4.6. I'm not sure I understand: using a pre-4.6 Texinfo will cause an error message for @documentencoding. Do you mean that the message will not be fatal, since we use --force? Even people who use Texinfo 4.6, many years from now, won't generally write @documentencoding in all their files. This is a manual that comes with Emacs, for which we can add that directive. As for manuals that are not part of Emacs, they _should_ use @documentencoding, and if they don't, we should submit bug reports to their authors. That is why I asked what it is that makes chinese-iso-8bit the default on his system. His language environment is Chinese, so chinese-iso-8bit is high on the priority list of encodings when insert-file-contents detects the encoding of the manual. And detect_coding is not smart enough to distinguish between Latin-N and chinese-iso-8bit, so it returns the latter as the highest priority encoding that (it thinks) fits the bill. Really, I think the only good way of solving this is to have a `coding:' tag in the Info file. Handa-san, do you agree? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
From: Richard Stallman [EMAIL PROTECTED] Date: Sat, 07 Jul 2007 16:46:53 -0400 Cc: emacs-pretest-bug@gnu.org On the other hand, we might also want to fix a coding system for Info files, so that their handling will not depend on the locale. How? Do you mean to encode Info files in UTF-8 or some such? That would not work well with the stand-alone Info reader, which is a text-mode program and thus limited to the character set supported by the underlying text terminal. Personally, I think preferring locale-specific encoding is TRT, since most of the installed manuals that use non-ASCII characters are more likely to use that than anything else. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
On the other hand, we might also want to fix a coding system for Info files, so that their handling will not depend on the locale. Handa and Karl, what do you think? If I'm understanding correctly, it can already be done. If you use the @documentencoding command in the Texinfo source, and then specify --enable-encoding to makeinfo, the resulting Info file(s) will contain a Local Variables section setting the `coding' variable. For instance, Local Variables: coding: iso-8859-2 End: This was done precisely so Emacs could know what encoding to use to display the Info file. karl ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Date: Sat, 7 Jul 2007 16:42:05 -0500 From: [EMAIL PROTECTED] (Karl Berry) Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED] If you use the @documentencoding command in the Texinfo source, and then specify --enable-encoding to makeinfo, the resulting Info file(s) will contain a Local Variables section setting the `coding' variable. Btw, why the need to specify --enable-encoding? Why don't makeinfo process @documentencoding by default? The problem with the command-line switch is that older versions of makeinfo will refuse to go ahead when an unknown to them switch is specified on the command line, whereas an unknown directive can be ignored by specifying --force (which we already do in Emacs). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
From: Zhang Wei [EMAIL PROTECTED] Date: Fri, 06 Jul 2007 09:56:08 +0800 This problem happens with emacs -Q, I don't think my .emacs cause this. Right. I managed to reproduce this problem on my machine in emacs -Q. The comments in emacs-mime.texi specify which coding system should be used to edit it: --8---cut here---start-8--- @c Local Variables: @c mode: texinfo @c coding: iso-8859-1 @c End: --8---cut here---end---8--- but the generated emacs-mime info file doesn't specify which coding should be used to view it. I think that's why emacs open it with the default coding system chinese-iso-8bit. Yes. Unfortunately, the way to fix this is not simple. The way to put an appropriate `coding:' tag in an Info file is to use the @documentencoding command in the Texinfo source, and then use the --enable-encoding command-line switch to makeinfo. But these two features were added in Texinfo 4.6, and I don't think we've decided to require such a new version (released in June 2003) yet. Richard, is it okay to assume Texinfo 4.6 for the CVS trunk? If it's okay, I can fix emacs-mime.texi and man/Makefile.in as described above. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
This problem happens with emacs -Q, I don't think my .emacs cause this. That is surely correct. The comments in emacs-mime.texi specify which coding system should be used to edit it: --8---cut here---start-8--- @c Local Variables: @c mode: texinfo @c coding: iso-8859-1 @c End: --8---cut here---end---8--- but the generated emacs-mime info file doesn't specify which coding should be used to view it. I think that's why emacs open it with the default coding system chinese-iso-8bit. Is this a bug, or is this correct behavior? What is it on your system that makes the default coding system chinese-iso-8bit? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Richard Stallman [EMAIL PROTECTED] writes: [...] What is it on your system that makes the default coding system chinese-iso-8bit? The default coding system is determined by Locale settings, that is `LC_ALL', `LC_CTYPE', or `LANG'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Richard Stallman [EMAIL PROTECTED] writes: Does the problem happen with emacs -Q? If it doesn't, then something in your .emacs init file causes this. Yes, it does. Could you show us the code in your .emacs file which caused this? It is possible that your .emacs file was incorrect. But it is also possible that your code is correct, and Emacs ought to be fixed to handle it better. When we see what your code says, we can figure that out. This problem happens with emacs -Q, I don't think my .emacs cause this. The comments in emacs-mime.texi specify which coding system should be used to edit it: --8---cut here---start-8--- @c Local Variables: @c mode: texinfo @c coding: iso-8859-1 @c End: --8---cut here---end---8--- but the generated emacs-mime info file doesn't specify which coding should be used to view it. I think that's why emacs open it with the default coding system chinese-iso-8bit. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
From: Zhang Wei [EMAIL PROTECTED] Date: Wed, 04 Jul 2007 21:56:40 +0800 When I enter Info, the info doc is allways opened with chinese-iso-8bit coding system which is the default of my installation. Thank you for reporting this. Unfortunately, I seem to be unable to reproduce this on my XP machine. Does the problem happen with emacs -Q? If it doesn't, then something in your .emacs init file causes this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
When I enter Info, the info doc is allways opened with chinese-iso-8bit coding system which is the default of my installation. If there are non-ascii characters in the doc, it will be displayed incorrectly, such as the emacs-mime page, there's a word `Naïve' in the page, and it should be opened with iso-8859-1. Since this depends on something unusual about your system, most of us cannot easily investigate it. Can you please investigate how this happens? I have cc'd Handa-san, whose area this is in. Please report back about whatever progress you can make. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Eli Zaretskii [EMAIL PROTECTED] writes: Does the problem happen with emacs -Q? If it doesn't, then something in your .emacs init file causes this. Yes, it does. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
