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
> 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
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
> 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: 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
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: 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
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
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
> 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
> 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
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
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
> 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
> 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
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
> 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
> 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
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
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
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
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
> 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
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
> 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. ___ 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
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
> 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
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. If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file c:/Emacs/etc/DEBUG for instructions. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-06-23 on BREP modified by Zhangwei <[EMAIL PROTECTED]>. Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.2)' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: CHS locale-coding-system: cp936 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: shell-dirtrack-mode: t auto-image-file-mode: t display-time-mode: t show-paren-mode: t delete-selection-mode: t pc-selection-mode: t encoded-kbd-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-x b C-h i C-x C-b M-< C-s c o d i n g - s y s t e m C-s C-s C-s C-r C-r C-r C-r C-g C-g C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-x b M-x r e p o r t - e m a c s - b u g h Recent messages: Quit Updating buffer list...done Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help Composing main Info directory...done Type C-x 1 to remove help window. Updating buffer list...done Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help Mark set Quit Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
