* A few bugs not in the bug tracker (I think) @ 2008-08-06 11:09 Juanma Barranquero 2008-08-06 12:31 ` Kenichi Handa 2008-08-06 13:35 ` Don Armstrong 0 siblings, 2 replies; 74+ messages in thread From: Juanma Barranquero @ 2008-08-06 11:09 UTC (permalink / raw To: Emacs Development The following open bugs are not in the bug tracker, I think. - face-valid-attribute-values chokes on font-family-list and new font-*-table vars http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00948.html - ^M in the info files [Windows] http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00739.html http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00215.html - Disappearing ^J in ChangeLogs [Windows] http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg02050.html http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00075.html - Crash displaying byte-code [Windows?] http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00236.html BTW, how do you know whether a bug has already been reported, other than perusing the open bug list? I see ways to search by bug #, package, maintainer e-mail, severity, tag, etc., but not a text search in the body of the messages (or even the subject). Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: A few bugs not in the bug tracker (I think) 2008-08-06 11:09 A few bugs not in the bug tracker (I think) Juanma Barranquero @ 2008-08-06 12:31 ` Kenichi Handa 2008-08-06 13:14 ` Juanma Barranquero 2008-08-06 18:04 ` A few bugs not in the bug tracker (I think) Eli Zaretskii 2008-08-06 13:35 ` Don Armstrong 1 sibling, 2 replies; 74+ messages in thread From: Kenichi Handa @ 2008-08-06 12:31 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel In article <f7ccd24b0808060409x7317e093i6918324c0c057687@mail.gmail.com>, "Juanma Barranquero" <lekktu@gmail.com> writes: > The following open bugs are not in the bug tracker, I think. > - face-valid-attribute-values chokes on font-family-list and new > font-*-table vars > http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00948.html I've just installed the fix. > - ^M in the info files [Windows] > http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00739.html > http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00215.html The problem is the newly introduced null-byte detection mechanism, but the discussion divergented to encoding of non-ascii characters, and for the original problem of null-byte in info file, no one replied to the question in this mail: http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00225.html > - Disappearing ^J in ChangeLogs [Windows] > http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg02050.html > http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00075.html Could someone please find a reproducible recipe? > - Crash displaying byte-code [Windows?] > http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00236.html I have not yet investigated that problem. At least, I can't reproduce it on X. --- Kenichi Handa handa@ni.aist.go.jp ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: A few bugs not in the bug tracker (I think) 2008-08-06 12:31 ` Kenichi Handa @ 2008-08-06 13:14 ` Juanma Barranquero 2008-08-06 13:36 ` Juanma Barranquero 2008-08-07 0:48 ` ^M in the info files Kenichi Handa 2008-08-06 18:04 ` A few bugs not in the bug tracker (I think) Eli Zaretskii 1 sibling, 2 replies; 74+ messages in thread From: Juanma Barranquero @ 2008-08-06 13:14 UTC (permalink / raw To: Kenichi Handa; +Cc: emacs-devel On Wed, Aug 6, 2008 at 14:31, Kenichi Handa <handa@m17n.org> wrote: >> The following open bugs are not in the bug tracker, I think. >> - face-valid-attribute-values chokes on font-family-list and new >> font-*-table vars > > I've just installed the fix. Thanks. One thing which was not in the bug report is that, on Windows, (face-valid-attribute-values :stipple) returns a list of all files in the current directory, because x-bitmap-file-path is "." on Windows. That seems a bit absurd. > The problem is the newly introduced null-byte detection > mechanism, but the discussion divergented to encoding of > non-ascii characters, and for the original problem of > null-byte in info file, no one replied to the question in > this mail: > http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00225.html How would inhibit-null-byte-detection work for info files? >> - Disappearing ^J in ChangeLogs [Windows] > > Could someone please find a reproducible recipe? Wish I could. I've set up modification hooks in my Emacs to try and find what is happening, or at least *when* it is happening. >> - Crash displaying byte-code [Windows?] >> http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00236.html > > I have not yet investigated that problem. At least, I can't > reproduce it on X. It might be related to font issues on Windows. Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: A few bugs not in the bug tracker (I think) 2008-08-06 13:14 ` Juanma Barranquero @ 2008-08-06 13:36 ` Juanma Barranquero 2008-08-07 4:25 ` Miles Bader 2008-08-07 0:48 ` ^M in the info files Kenichi Handa 1 sibling, 1 reply; 74+ messages in thread From: Juanma Barranquero @ 2008-08-06 13:36 UTC (permalink / raw To: Kenichi Handa; +Cc: emacs-devel >> - face-valid-attribute-values chokes on font-family-list and new >> font-*-table vars BTW, speaking of face attributes... Is this (from bug #648) a bug? Emacs 22.X: (face-attribute 'default :inherit) => unspecified Emacs 23.X: (face-attribute 'default :inherit) => nil Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: A few bugs not in the bug tracker (I think) 2008-08-06 13:36 ` Juanma Barranquero @ 2008-08-07 4:25 ` Miles Bader 2008-08-07 11:26 ` Juanma Barranquero 0 siblings, 1 reply; 74+ messages in thread From: Miles Bader @ 2008-08-07 4:25 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel, Kenichi Handa "Juanma Barranquero" <lekktu@gmail.com> writes: > BTW, speaking of face attributes... Is this (from bug #648) a bug? > > Emacs 22.X: (face-attribute 'default :inherit) => unspecified > Emacs 23.X: (face-attribute 'default :inherit) => nil No. The default face shouldn't have any unspecified attributes. Well, I suppose you could consider it a bug in 22.x, though probably not a very important one... -Miles -- Quack, n. A murderer without a license. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: A few bugs not in the bug tracker (I think) 2008-08-07 4:25 ` Miles Bader @ 2008-08-07 11:26 ` Juanma Barranquero 0 siblings, 0 replies; 74+ messages in thread From: Juanma Barranquero @ 2008-08-07 11:26 UTC (permalink / raw To: Miles Bader; +Cc: emacs-devel, Kenichi Handa On Thu, Aug 7, 2008 at 06:25, Miles Bader <miles.bader@necel.com> wrote: > No. > > The default face shouldn't have any unspecified attributes. OK. > Well, I suppose you could consider it a bug in 22.x, though probably not > a very important one... Agreed. Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-08-06 13:14 ` Juanma Barranquero 2008-08-06 13:36 ` Juanma Barranquero @ 2008-08-07 0:48 ` Kenichi Handa 2008-08-07 3:20 ` Eli Zaretskii ` (2 more replies) 1 sibling, 3 replies; 74+ messages in thread From: Kenichi Handa @ 2008-08-07 0:48 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel I changed the Subject: In article <f7ccd24b0808060614h4917f240oc261b8fedff0e8d0@mail.gmail.com>, "Juanma Barranquero" <lekktu@gmail.com> writes: > > The problem is the newly introduced null-byte detection > > mechanism, but the discussion divergented to encoding of > > non-ascii characters, and for the original problem of > > null-byte in info file, no one replied to the question in > > this mail: > > http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00225.html > How would inhibit-null-byte-detection work for info files? For instance, by modifying info-insert-file-contents to bind that variable to t while reading a file. Eli Zaretskii <eliz@gnu.org> writes: > I think the best solution would be that Emacs never tries to detect > whether Info files are binary. Do you have any idea to achieve that? --- Kenichi Handa handa@ni.aist.go.jp ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-08-07 0:48 ` ^M in the info files Kenichi Handa @ 2008-08-07 3:20 ` Eli Zaretskii 2008-08-07 3:22 ` Juanma Barranquero 2008-08-07 20:18 ` Stefan Monnier 2 siblings, 0 replies; 74+ messages in thread From: Eli Zaretskii @ 2008-08-07 3:20 UTC (permalink / raw To: Kenichi Handa; +Cc: lekktu, emacs-devel > From: Kenichi Handa <handa@m17n.org> > Date: Thu, 07 Aug 2008 09:48:37 +0900 > Cc: emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org> writes: > > > I think the best solution would be that Emacs never tries to detect > > whether Info files are binary. > > Do you have any idea to achieve that? Sorry, not yet. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-08-07 0:48 ` ^M in the info files Kenichi Handa 2008-08-07 3:20 ` Eli Zaretskii @ 2008-08-07 3:22 ` Juanma Barranquero 2008-08-07 3:47 ` Kenichi Handa 2008-08-07 20:18 ` Stefan Monnier 2 siblings, 1 reply; 74+ messages in thread From: Juanma Barranquero @ 2008-08-07 3:22 UTC (permalink / raw To: Kenichi Handa; +Cc: emacs-devel On Thu, Aug 7, 2008 at 02:48, Kenichi Handa <handa@m17n.org> wrote: > For instance, by modifying info-insert-file-contents to bind > that variable to t while reading a file. Aha. Well, that's a possible solution then. Is there any downside to it? Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-08-07 3:22 ` Juanma Barranquero @ 2008-08-07 3:47 ` Kenichi Handa 2008-08-07 13:01 ` Juanma Barranquero 0 siblings, 1 reply; 74+ messages in thread From: Kenichi Handa @ 2008-08-07 3:47 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel In article <f7ccd24b0808062022t71035360h5f120bcade3363e8@mail.gmail.com>, "Juanma Barranquero" <lekktu@gmail.com> writes: > On Thu, Aug 7, 2008 at 02:48, Kenichi Handa <handa@m17n.org> wrote: > > For instance, by modifying info-insert-file-contents to bind > > that variable to t while reading a file. > Aha. > Well, that's a possible solution then. Is there any downside to it? I don't see any bad effect to it. But, as I'm not familiar with the code of info, I don't know which place is the best to bind that variable. --- Kenichi Handa handa@ni.aist.go.jp ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-08-07 3:47 ` Kenichi Handa @ 2008-08-07 13:01 ` Juanma Barranquero 2008-08-08 1:28 ` Kenichi Handa 0 siblings, 1 reply; 74+ messages in thread From: Juanma Barranquero @ 2008-08-07 13:01 UTC (permalink / raw To: Kenichi Handa; +Cc: emacs-devel On Thu, Aug 7, 2008 at 05:47, Kenichi Handa <handa@m17n.org> wrote: > I don't see any bad effect to it. But, as I'm not familiar > with the code of info, I don't know which place is the best > to bind that variable. I've tried implementing your suggestion; see the attached patch. It works for uncompressed info files, and for compressed ones when auto-compression-mode is off. However, when auto-compression-mode is on, the conversion depends on the settings of `file-coding-system-alist' for the given compression method. Juanma Index: src/coding.c =================================================================== RCS file: /sources/emacs/emacs/src/coding.c,v retrieving revision 1.390 diff -u -2 -r1.390 coding.c --- src/coding.c 9 Jul 2008 13:05:56 -0000 1.390 +++ src/coding.c 7 Aug 2008 10:42:46 -0000 @@ -381,4 +381,7 @@ int inhibit_iso_escape_detection; +/* Flag to inhibit detection of binary files through null bytes. */ +int inhibit_null_byte_detection; + /* Flag to make buffer-file-coding-system inherit from process-coding. */ int inherit_process_coding_system; @@ -5895,5 +5898,5 @@ if (i < coding_category_raw_text) setup_coding_system (CODING_ID_NAME (this->id), coding); - else if (null_byte_found) + else if (null_byte_found && ! inhibit_null_byte_detection) setup_coding_system (Qno_conversion, coding); else if ((detect_info.rejected & CATEGORY_MASK_ANY) @@ -10233,4 +10236,23 @@ inhibit_iso_escape_detection = 0; + DEFVAR_BOOL ("inhibit-null-byte-detection", + &inhibit_null_byte_detection, + doc: /* +If non-nil, Emacs ignores null bytes on code detection. + +By default, on reading a file, Emacs tries to detect how the text is +encoded. This code detection is sensitive to null bytes. If the +text contains null bytes, the file is determined as containing +binary data. + +However, there may be a case that you want to read non-binary data +that contains null bytes. In such a case, you can set this variable +to non-nil. + +The default value is nil, and it is strongly recommended not to change +it. This variable is intended to be bound to t in the few instances +where that is useful, for example to read certain info files. */); + inhibit_null_byte_detection = 0; + DEFVAR_LISP ("translation-table-for-input", &Vtranslation_table_for_input, doc: /* Char table for translating self-inserting characters. Index: lisp/info.el =================================================================== RCS file: /sources/emacs/emacs/lisp/info.el,v retrieving revision 1.540 diff -u -2 -r1.540 info.el --- lisp/info.el 30 Jul 2008 17:16:46 -0000 1.540 +++ lisp/info.el 7 Aug 2008 11:20:36 -0000 @@ -456,5 +456,6 @@ (apply 'call-process-region (point-min) (point-max) (car decoder) t t nil (cdr decoder)))) - (insert-file-contents fullname visit)))) + (let ((inhibit-null-byte-detection t)) + (insert-file-contents fullname visit))))) \f (defun Info-default-dirs () ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-08-07 13:01 ` Juanma Barranquero @ 2008-08-08 1:28 ` Kenichi Handa 2008-08-08 11:02 ` Juanma Barranquero 0 siblings, 1 reply; 74+ messages in thread From: Kenichi Handa @ 2008-08-08 1:28 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel In article <f7ccd24b0808070601i2897b57ak98d6343b2442f40c@mail.gmail.com>, "Juanma Barranquero" <lekktu@gmail.com> writes: > On Thu, Aug 7, 2008 at 05:47, Kenichi Handa <handa@m17n.org> wrote: > > I don't see any bad effect to it. But, as I'm not familiar > > with the code of info, I don't know which place is the best > > to bind that variable. > I've tried implementing your suggestion; see the attached patch. Thank you! > It works for uncompressed info files, and for compressed ones when > auto-compression-mode is off. > However, when auto-compression-mode is on, the conversion depends on > the settings of `file-coding-system-alist' for the given compression > method. You handled inhibit_iso_escape_detection only in detect_coding. Isn't the problem fixed by modifing the detect_coding_system too. That funciton does code detection when called from detect-coding-region/string. --- Kenichi Handa handa@ni.aist.go.jp ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-08-08 1:28 ` Kenichi Handa @ 2008-08-08 11:02 ` Juanma Barranquero 2008-08-13 10:08 ` Kenichi Handa 0 siblings, 1 reply; 74+ messages in thread From: Juanma Barranquero @ 2008-08-08 11:02 UTC (permalink / raw To: Kenichi Handa; +Cc: emacs-devel On Fri, Aug 8, 2008 at 03:28, Kenichi Handa <handa@m17n.org> wrote: > You handled inhibit_iso_escape_detection only in > detect_coding. Isn't the problem fixed by modifing the > detect_coding_system too. Well, you give me too much credit; I just did the easiest change that could possibly work :-) [It didn't] But AFAICS, the trouble with compressed info files is not because of null-byte detection. If I gzip efaq and then visit it through Info, the buffer is detected as utf-8-unix, not no-conversion. Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-08-08 11:02 ` Juanma Barranquero @ 2008-08-13 10:08 ` Kenichi Handa 2008-08-15 23:09 ` Juanma Barranquero 0 siblings, 1 reply; 74+ messages in thread From: Kenichi Handa @ 2008-08-13 10:08 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel In article <f7ccd24b0808080402m2d2b958aq9fe7f82a25d7b48d@mail.gmail.com>, "Juanma Barranquero" <lekktu@gmail.com> writes: > On Fri, Aug 8, 2008 at 03:28, Kenichi Handa <handa@m17n.org> wrote: > > You handled inhibit_iso_escape_detection only in > > detect_coding. Isn't the problem fixed by modifing the > > detect_coding_system too. > Well, you give me too much credit; I just did the easiest change that > could possibly work :-) [It didn't] > But AFAICS, the trouble with compressed info files is not because of > null-byte detection. If I gzip efaq and then visit it through Info, > the buffer is detected as utf-8-unix, not no-conversion. Do you mean that utf-8-unix is an incorrect detection? Or, are there any other problems? --- Kenichi Handa handa@ni.aist.go.jp ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-08-13 10:08 ` Kenichi Handa @ 2008-08-15 23:09 ` Juanma Barranquero 0 siblings, 0 replies; 74+ messages in thread From: Juanma Barranquero @ 2008-08-15 23:09 UTC (permalink / raw To: Kenichi Handa; +Cc: emacs-devel On Wed, Aug 13, 2008 at 12:08, Kenichi Handa <handa@m17n.org> wrote: > Do you mean that utf-8-unix is an incorrect detection? Well, I would have expected that, if it detected the file as utf-8-dos the CR/LF pairs would be correctly shown... (I'm talking of the case of a gzipped Windows-generated info file). Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-08-07 0:48 ` ^M in the info files Kenichi Handa 2008-08-07 3:20 ` Eli Zaretskii 2008-08-07 3:22 ` Juanma Barranquero @ 2008-08-07 20:18 ` Stefan Monnier 2008-11-28 21:28 ` Drew Adams 2 siblings, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2008-08-07 20:18 UTC (permalink / raw To: Kenichi Handa; +Cc: Juanma Barranquero, emacs-devel >> How would inhibit-null-byte-detection work for info files? > For instance, by modifying info-insert-file-contents to bind > that variable to t while reading a file. An alternative to inhibit-null-byte-detection would be something like inhibit-coding-systems which would contain a list of coding systems (or maybe coding categories?) we know we don't want to use. Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* RE: ^M in the info files 2008-08-07 20:18 ` Stefan Monnier @ 2008-11-28 21:28 ` Drew Adams 2008-11-28 22:39 ` Eli Zaretskii 0 siblings, 1 reply; 74+ messages in thread From: Drew Adams @ 2008-11-28 21:28 UTC (permalink / raw To: 'Stefan Monnier', 'Kenichi Handa' Cc: 'Juanma Barranquero', emacs-devel > From: Stefan Monnier Sent: Thursday, August 07, 2008 1:19 PM > >> How would inhibit-null-byte-detection work for info files? > > > > For instance, by modifying info-insert-file-contents to bind > > that variable to t while reading a file. > > An alternative to inhibit-null-byte-detection would be something like > inhibit-coding-systems which would contain a list of coding > systems (or maybe coding categories?) we know we don't want to use. Whatever happened to this thread and the associated bugs: #876, #1117, #1284? It sounds like there were alternative proposals about how to fix this, but there was no discussion to try to reach a consensus or a decision. Is that where things were left? Meanwhile, it's still impossible to use the index in Info manuals on Windows, and it's impossible to use some manuals (e.g. Viper) at all. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-11-28 21:28 ` Drew Adams @ 2008-11-28 22:39 ` Eli Zaretskii 2008-11-28 22:44 ` Juanma Barranquero ` (2 more replies) 0 siblings, 3 replies; 74+ messages in thread From: Eli Zaretskii @ 2008-11-28 22:39 UTC (permalink / raw To: Drew Adams; +Cc: lekktu, emacs-devel, monnier, handa > From: "Drew Adams" <drew.adams@oracle.com> > Date: Fri, 28 Nov 2008 13:28:34 -0800 > Cc: 'Juanma Barranquero' <lekktu@gmail.com>, emacs-devel@gnu.org > > Whatever happened to this thread and the associated bugs: #876, #1117, #1284? > > It sounds like there were alternative proposals about how to fix this, but there > was no discussion to try to reach a consensus or a decision. Is that where > things were left? > > Meanwhile, it's still impossible to use the index in Info manuals on Windows, > and it's impossible to use some manuals (e.g. Viper) at all. Don't worry, this will get fixed before Emacs 23 is ready for release. I will work on it soon if no one beats me to it. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-11-28 22:39 ` Eli Zaretskii @ 2008-11-28 22:44 ` Juanma Barranquero 2008-11-29 10:50 ` Eli Zaretskii 2008-11-28 22:49 ` Drew Adams 2009-01-10 11:15 ` Eli Zaretskii 2 siblings, 1 reply; 74+ messages in thread From: Juanma Barranquero @ 2008-11-28 22:44 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel On Fri, Nov 28, 2008 at 23:39, Eli Zaretskii <eliz@gnu.org> wrote: > I will work on it soon if no one beats me to it. How are you going to fix it? Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-11-28 22:44 ` Juanma Barranquero @ 2008-11-29 10:50 ` Eli Zaretskii 2008-11-29 11:56 ` Juanma Barranquero 0 siblings, 1 reply; 74+ messages in thread From: Eli Zaretskii @ 2008-11-29 10:50 UTC (permalink / raw To: Juanma Barranquero; +Cc: emacs-devel > Date: Fri, 28 Nov 2008 23:44:49 +0100 > From: "Juanma Barranquero" <lekktu@gmail.com> > Cc: emacs-devel@gnu.org > > On Fri, Nov 28, 2008 at 23:39, Eli Zaretskii <eliz@gnu.org> wrote: > > > I will work on it soon if no one beats me to it. > > How are you going to fix it? I don't know yet; figuring that out is part of the job. Last time when I had a few hours to work on this, my Internet connection died in the middle of reading past messages about this problem, and came back up when the time I had was up. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-11-29 10:50 ` Eli Zaretskii @ 2008-11-29 11:56 ` Juanma Barranquero 0 siblings, 0 replies; 74+ messages in thread From: Juanma Barranquero @ 2008-11-29 11:56 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel On Sat, Nov 29, 2008 at 11:50, Eli Zaretskii <eliz@gnu.org> wrote: > Last time when I had a few hours to work on this, my Internet > connection died in the middle of reading past messages about this > problem, and came back up when the time I had was up. An omen if I ever saw one... Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* RE: ^M in the info files 2008-11-28 22:39 ` Eli Zaretskii 2008-11-28 22:44 ` Juanma Barranquero @ 2008-11-28 22:49 ` Drew Adams 2008-11-29 10:51 ` Eli Zaretskii 2009-01-10 11:15 ` Eli Zaretskii 2 siblings, 1 reply; 74+ messages in thread From: Drew Adams @ 2008-11-28 22:49 UTC (permalink / raw To: 'Eli Zaretskii'; +Cc: lekktu, emacs-devel, monnier, handa > > Whatever happened to this thread and the associated bugs: > > #876, #1117, #1284? > > > > It sounds like there were alternative proposals about how > > to fix this, but there was no discussion to try to reach a > > consensus or a decision. Is that where things were left? > > > > Meanwhile, it's still impossible to use the index in Info > > manuals on Windows, and it's impossible to use some manuals > > (e.g. Viper) at all. > > Don't worry, this will get fixed before Emacs 23 is ready for release. > I will work on it soon if no one beats me to it. OK, thanks. But what will you do? It sounds like nothing was decided wrt the fix that's needed. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-11-28 22:49 ` Drew Adams @ 2008-11-29 10:51 ` Eli Zaretskii 0 siblings, 0 replies; 74+ messages in thread From: Eli Zaretskii @ 2008-11-29 10:51 UTC (permalink / raw To: Drew Adams; +Cc: emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <monnier@iro.umontreal.ca>, <handa@m17n.org>, <lekktu@gmail.com>, > <emacs-devel@gnu.org> > Date: Fri, 28 Nov 2008 14:49:32 -0800 > > > Don't worry, this will get fixed before Emacs 23 is ready for release. > > I will work on it soon if no one beats me to it. > > OK, thanks. > > But what will you do? > It sounds like nothing was decided wrt the fix that's needed. Obviously, I will need first to decide which of the two suggested approaches I like best. Or maybe I will come up with some third solution. I will know when I actually start working on this. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2008-11-28 22:39 ` Eli Zaretskii 2008-11-28 22:44 ` Juanma Barranquero 2008-11-28 22:49 ` Drew Adams @ 2009-01-10 11:15 ` Eli Zaretskii 2008-09-03 16:39 ` bug#876: ^M in some Windows info files because of null-byte detection Juanma Barranquero ` (7 more replies) 2 siblings, 8 replies; 74+ messages in thread From: Eli Zaretskii @ 2009-01-10 11:15 UTC (permalink / raw To: 876-done; +Cc: emacs-pretest-bug, bug-gnu-emacs, emacs-devel > Date: Sat, 29 Nov 2008 00:39:27 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: lekktu@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, > handa@m17n.org > > > From: "Drew Adams" <drew.adams@oracle.com> > > Date: Fri, 28 Nov 2008 13:28:34 -0800 > > Cc: 'Juanma Barranquero' <lekktu@gmail.com>, emacs-devel@gnu.org > > > > Whatever happened to this thread and the associated bugs: #876, #1117, #1284? > > > > It sounds like there were alternative proposals about how to fix this, but there > > was no discussion to try to reach a consensus or a decision. Is that where > > things were left? > > > > Meanwhile, it's still impossible to use the index in Info manuals on Windows, > > and it's impossible to use some manuals (e.g. Viper) at all. > > Don't worry, this will get fixed before Emacs 23 is ready for release. > > I will work on it soon if no one beats me to it. (Fore some value of "soon", sorry.) I fixed this bug. There were two suggestions for how to fix this: one by Handa-san in this message: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00293.html followed by a tentative patch by Juanma here: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00316.html The other suggestion was by Stefan: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00373.html I decided I liked the first alternative better, since it has much more local effect than the other one. What Stefan suggested implied messing with coding priorities, and I didn't feel that was TRT at this late stage in Emacs 23.1 development. The changes I installed are more thorough than what Juanma posted: they change both detect_coding and detect_coding_system, and also bind inhibit-null-byte-detection in a couple more places in info.el. The result was tested on GNU/Linux, MS-Windows, and MS-DOS, both with compressed and uncompressed Info files, with auto-compression-mode both on and off. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#876: ^M in some Windows info files because of null-byte detection @ 2008-09-03 16:39 ` Juanma Barranquero 2009-01-10 11:25 ` bug#876: marked as done (^M in some Windows info files because of null-byte detection) Emacs bug Tracking System 0 siblings, 1 reply; 74+ messages in thread From: Juanma Barranquero @ 2008-09-03 16:39 UTC (permalink / raw To: Emacs Bug Tracker Some info files in Windows (for example, the Emacs FAQ) are displayed with spurious ^M characters because of recent changes in null byte detection. Kenichi Handa proposed a new inhibit-null-byte-detection variable. Stefan Monnier counter-proposed inhibit-coding-systems. emacs-devel discussion: http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00739.html http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00215.html http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00225.html http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00293.html ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#876: marked as done (^M in some Windows info files because of null-byte detection) 2008-09-03 16:39 ` bug#876: ^M in some Windows info files because of null-byte detection Juanma Barranquero @ 2009-01-10 11:25 ` Emacs bug Tracking System 0 siblings, 0 replies; 74+ messages in thread From: Emacs bug Tracking System @ 2009-01-10 11:25 UTC (permalink / raw To: Eli Zaretskii [-- Attachment #1: Type: text/plain, Size: 858 bytes --] Your message dated Sat, 10 Jan 2009 13:15:51 +0200 with message-id <uab9zjtso.fsf@gnu.org> and subject line Re: ^M in the info files has caused the Emacs bug report #876, regarding ^M in some Windows info files because of null-byte detection to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com immediately.) -- 876: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=876 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 2791 bytes --] From: "Juanma Barranquero" <lekktu@gmail.com> To: "Emacs Bug Tracker" <submit@emacsbugs.donarmstrong.com> Subject: ^M in some Windows info files because of null-byte detection Date: Wed, 3 Sep 2008 18:39:11 +0200 Message-ID: <f7ccd24b0809030939l67318d7bkc924a8f1cf780c07@mail.gmail.com> Some info files in Windows (for example, the Emacs FAQ) are displayed with spurious ^M characters because of recent changes in null byte detection. Kenichi Handa proposed a new inhibit-null-byte-detection variable. Stefan Monnier counter-proposed inhibit-coding-systems. emacs-devel discussion: http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00739.html http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00215.html http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00225.html http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00293.html [-- Attachment #3: Type: message/rfc822, Size: 3682 bytes --] From: Eli Zaretskii <eliz@gnu.org> To: 876-done@emacsbugs.donarmstrong.com Cc: emacs-devel@gnu.org, bug-gnu-emacs@gnu.org, emacs-pretest-bug@gnu.org Subject: Re: ^M in the info files Date: Sat, 10 Jan 2009 13:15:51 +0200 Message-ID: <uab9zjtso.fsf@gnu.org> > Date: Sat, 29 Nov 2008 00:39:27 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: lekktu@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, > handa@m17n.org > > > From: "Drew Adams" <drew.adams@oracle.com> > > Date: Fri, 28 Nov 2008 13:28:34 -0800 > > Cc: 'Juanma Barranquero' <lekktu@gmail.com>, emacs-devel@gnu.org > > > > Whatever happened to this thread and the associated bugs: #876, #1117, #1284? > > > > It sounds like there were alternative proposals about how to fix this, but there > > was no discussion to try to reach a consensus or a decision. Is that where > > things were left? > > > > Meanwhile, it's still impossible to use the index in Info manuals on Windows, > > and it's impossible to use some manuals (e.g. Viper) at all. > > Don't worry, this will get fixed before Emacs 23 is ready for release. > > I will work on it soon if no one beats me to it. (Fore some value of "soon", sorry.) I fixed this bug. There were two suggestions for how to fix this: one by Handa-san in this message: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00293.html followed by a tentative patch by Juanma here: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00316.html The other suggestion was by Stefan: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00373.html I decided I liked the first alternative better, since it has much more local effect than the other one. What Stefan suggested implied messing with coding priorities, and I didn't feel that was TRT at this late stage in Emacs 23.1 development. The changes I installed are more thorough than what Juanma posted: they change both detect_coding and detect_coding_system, and also bind inhibit-null-byte-detection in a couple more places in info.el. The result was tested on GNU/Linux, MS-Windows, and MS-DOS, both with compressed and uncompressed Info files, with auto-compression-mode both on and off. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1117: 23.0.60; Index in Elisp manual has ^M at the end of each line @ 2008-10-08 6:49 ` Drew Adams 2008-10-08 8:02 ` Juanma Barranquero 2009-01-10 11:25 ` bug#1117: marked as done (23.0.60; Index in Elisp manual has ^M at the end of each line) Emacs bug Tracking System 0 siblings, 2 replies; 74+ messages in thread From: Drew Adams @ 2008-10-08 6:49 UTC (permalink / raw To: emacs-pretest-bug emacs -Q C-h i, choose Elisp manual g Index takes you to the Index node. Each line has a visible ^M at the end of it. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-10-03 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' 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: ENU value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: <help-echo> C-h i <help-echo> <help-echo> <help-echo> <down-mouse-2> <mouse-2> <double-down-mouse-2> <double-mouse-2> <help-echo> g I n d e x <return> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> <send-emacs-bug-report> Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Composing main Info directory...done ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1117: 23.0.60; Index in Elisp manual has ^M at the end of each line 2008-10-08 6:49 ` bug#1117: 23.0.60; Index in Elisp manual has ^M at the end of each line Drew Adams @ 2008-10-08 8:02 ` Juanma Barranquero 2008-10-08 10:01 ` Eli Zaretskii 2008-10-08 14:10 ` Drew Adams 2009-01-10 11:25 ` bug#1117: marked as done (23.0.60; Index in Elisp manual has ^M at the end of each line) Emacs bug Tracking System 1 sibling, 2 replies; 74+ messages in thread From: Juanma Barranquero @ 2008-10-08 8:02 UTC (permalink / raw To: Drew Adams, 1117 > emacs -Q > C-h i, choose Elisp manual > g Index takes you to the Index node. > > Each line has a visible ^M at the end of it. That's surely #876? Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1117: 23.0.60; Index in Elisp manual has ^M at the end of each line 2008-10-08 8:02 ` Juanma Barranquero @ 2008-10-08 10:01 ` Eli Zaretskii 2008-10-08 16:52 ` Juanma Barranquero 2008-10-08 14:10 ` Drew Adams 1 sibling, 1 reply; 74+ messages in thread From: Eli Zaretskii @ 2008-10-08 10:01 UTC (permalink / raw To: Juanma Barranquero, 1117; +Cc: bug-gnu-emacs > Date: Wed, 8 Oct 2008 10:02:40 +0200 > From: "Juanma Barranquero" <lekktu@gmail.com> > Cc: > > > emacs -Q > > C-h i, choose Elisp manual > > g Index takes you to the Index node. > > > > Each line has a visible ^M at the end of it. > > That's surely #876? I thought #876 was resolved long ago. Why wasn't it? ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1117: 23.0.60; Index in Elisp manual has ^M at the end of each line 2008-10-08 10:01 ` Eli Zaretskii @ 2008-10-08 16:52 ` Juanma Barranquero 0 siblings, 0 replies; 74+ messages in thread From: Juanma Barranquero @ 2008-10-08 16:52 UTC (permalink / raw To: Eli Zaretskii; +Cc: 1117 On Wed, Oct 8, 2008 at 12:01, Eli Zaretskii <eliz@gnu.org> wrote: > I thought #876 was resolved long ago. Why wasn't it? As the bug report says: Kenichi Handa proposed a new inhibit-null-byte-detection variable. Stefan Monnier counter-proposed inhibit-coding-systems. Then things stalled. Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1117: 23.0.60; Index in Elisp manual has ^M at the end of each line 2008-10-08 8:02 ` Juanma Barranquero 2008-10-08 10:01 ` Eli Zaretskii @ 2008-10-08 14:10 ` Drew Adams 1 sibling, 0 replies; 74+ messages in thread From: Drew Adams @ 2008-10-08 14:10 UTC (permalink / raw To: 'Juanma Barranquero', 1117 > > emacs -Q > > C-h i, choose Elisp manual > > g Index takes you to the Index node. > > > > Each line has a visible ^M at the end of it. > > That's surely #876? Yeah, kinda looks like it. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1117: marked as done (23.0.60; Index in Elisp manual has ^M at the end of each line) 2008-10-08 6:49 ` bug#1117: 23.0.60; Index in Elisp manual has ^M at the end of each line Drew Adams 2008-10-08 8:02 ` Juanma Barranquero @ 2009-01-10 11:25 ` Emacs bug Tracking System 1 sibling, 0 replies; 74+ messages in thread From: Emacs bug Tracking System @ 2009-01-10 11:25 UTC (permalink / raw To: Eli Zaretskii [-- Attachment #1: Type: text/plain, Size: 859 bytes --] Your message dated Sat, 10 Jan 2009 13:15:51 +0200 with message-id <uab9zjtso.fsf@gnu.org> and subject line Re: ^M in the info files has caused the Emacs bug report #876, regarding 23.0.60; Index in Elisp manual has ^M at the end of each line to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com immediately.) -- 876: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=876 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 4071 bytes --] From: "Drew Adams" <drew.adams@oracle.com> To: <emacs-pretest-bug@gnu.org> Subject: 23.0.60; Index in Elisp manual has ^M at the end of each line Date: Tue, 7 Oct 2008 23:49:07 -0700 Message-ID: <008a01c92911$f6510ee0$0200a8c0@us.oracle.com> emacs -Q C-h i, choose Elisp manual g Index takes you to the Index node. Each line has a visible ^M at the end of it. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-10-03 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' 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: ENU value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: <help-echo> C-h i <help-echo> <help-echo> <help-echo> <down-mouse-2> <mouse-2> <double-down-mouse-2> <double-mouse-2> <help-echo> g I n d e x <return> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> <send-emacs-bug-report> Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Composing main Info directory...done [-- Attachment #3: Type: message/rfc822, Size: 3682 bytes --] From: Eli Zaretskii <eliz@gnu.org> To: 876-done@emacsbugs.donarmstrong.com Cc: emacs-devel@gnu.org, bug-gnu-emacs@gnu.org, emacs-pretest-bug@gnu.org Subject: Re: ^M in the info files Date: Sat, 10 Jan 2009 13:15:51 +0200 Message-ID: <uab9zjtso.fsf@gnu.org> > Date: Sat, 29 Nov 2008 00:39:27 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: lekktu@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, > handa@m17n.org > > > From: "Drew Adams" <drew.adams@oracle.com> > > Date: Fri, 28 Nov 2008 13:28:34 -0800 > > Cc: 'Juanma Barranquero' <lekktu@gmail.com>, emacs-devel@gnu.org > > > > Whatever happened to this thread and the associated bugs: #876, #1117, #1284? > > > > It sounds like there were alternative proposals about how to fix this, but there > > was no discussion to try to reach a consensus or a decision. Is that where > > things were left? > > > > Meanwhile, it's still impossible to use the index in Info manuals on Windows, > > and it's impossible to use some manuals (e.g. Viper) at all. > > Don't worry, this will get fixed before Emacs 23 is ready for release. > > I will work on it soon if no one beats me to it. (Fore some value of "soon", sorry.) I fixed this bug. There were two suggestions for how to fix this: one by Handa-san in this message: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00293.html followed by a tentative patch by Juanma here: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00316.html The other suggestion was by Stefan: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00373.html I decided I liked the first alternative better, since it has much more local effect than the other one. What Stefan suggested implied messing with coding priorities, and I didn't feel that was TRT at this late stage in Emacs 23.1 development. The changes I installed are more thorough than what Juanma posted: they change both detect_coding and detect_coding_system, and also bind inhibit-null-byte-detection in a couple more places in info.el. The result was tested on GNU/Linux, MS-Windows, and MS-DOS, both with compressed and uncompressed Info files, with auto-compression-mode both on and off. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1284: 23.0.60; ^M throughout Viper manual @ 2008-10-31 15:56 ` Drew Adams 2008-10-31 16:26 ` Drew Adams ` (3 more replies) 0 siblings, 4 replies; 74+ messages in thread From: Drew Adams @ 2008-10-31 15:56 UTC (permalink / raw To: emacs-pretest-bug Subject line says it all In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-10-09 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1284: 23.0.60; ^M throughout Viper manual 2008-10-31 15:56 ` bug#1284: 23.0.60; ^M throughout Viper manual Drew Adams @ 2008-10-31 16:26 ` Drew Adams 2008-10-31 18:41 ` Eli Zaretskii 2008-10-31 16:26 ` Juanma Barranquero ` (2 subsequent siblings) 3 siblings, 1 reply; 74+ messages in thread From: Drew Adams @ 2008-10-31 16:26 UTC (permalink / raw To: 1284, emacs-pretest-bug Also, the manual name should be listed in `dir' as `Viper', not `VIPER'. Throughout the Viper manual, Viper is referred to as `Viper', not `VIPER'. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1284: 23.0.60; ^M throughout Viper manual 2008-10-31 16:26 ` Drew Adams @ 2008-10-31 18:41 ` Eli Zaretskii 0 siblings, 0 replies; 74+ messages in thread From: Eli Zaretskii @ 2008-10-31 18:41 UTC (permalink / raw To: Drew Adams, 1284; +Cc: emacs-pretest-bug, bug-gnu-emacs > From: "Drew Adams" <drew.adams@oracle.com> > Date: Fri, 31 Oct 2008 09:26:02 -0700 > Cc: > > Also, the manual name should be listed in `dir' as `Viper', not `VIPER'. > Throughout the Viper manual, Viper is referred to as `Viper', not `VIPER'. We just honor the manual's request here, which specifies this DIR entry in viper.texi: @direntry * VIPER: (viper). The newest Emacs VI-emulation mode. (also, A VI Plan for Emacs Rescue or the VI PERil.) @end direntry So it sounds like VIPER is actually an acronym, or at least it used to be. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1284: 23.0.60; ^M throughout Viper manual 2008-10-31 15:56 ` bug#1284: 23.0.60; ^M throughout Viper manual Drew Adams 2008-10-31 16:26 ` Drew Adams @ 2008-10-31 16:26 ` Juanma Barranquero 2008-10-31 20:47 ` Leo 2009-01-10 11:25 ` bug#1284: marked as done (23.0.60; ^M throughout Viper manual) Emacs bug Tracking System 3 siblings, 0 replies; 74+ messages in thread From: Juanma Barranquero @ 2008-10-31 16:26 UTC (permalink / raw To: Drew Adams; +Cc: 1284 reassign 1284 emacs,w32 merge 876 1284 quit > Subject line says it all That's bug#876, which you already reported previously as #1117 Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1284: 23.0.60; ^M throughout Viper manual 2008-10-31 15:56 ` bug#1284: 23.0.60; ^M throughout Viper manual Drew Adams 2008-10-31 16:26 ` Drew Adams 2008-10-31 16:26 ` Juanma Barranquero @ 2008-10-31 20:47 ` Leo 2009-01-10 11:25 ` bug#1284: marked as done (23.0.60; ^M throughout Viper manual) Emacs bug Tracking System 3 siblings, 0 replies; 74+ messages in thread From: Leo @ 2008-10-31 20:47 UTC (permalink / raw To: emacs-pretest-bug; +Cc: bug-gnu-emacs On 2008-10-31 15:56 +0000, Drew Adams wrote: > Subject line says it all I think a few other info files also has the same problem. -- .: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :. Use the better alternative -- http://www.openoffice.org/ ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1284: marked as done (23.0.60; ^M throughout Viper manual) 2008-10-31 15:56 ` bug#1284: 23.0.60; ^M throughout Viper manual Drew Adams ` (2 preceding siblings ...) 2008-10-31 20:47 ` Leo @ 2009-01-10 11:25 ` Emacs bug Tracking System 3 siblings, 0 replies; 74+ messages in thread From: Emacs bug Tracking System @ 2009-01-10 11:25 UTC (permalink / raw To: Eli Zaretskii [-- Attachment #1: Type: text/plain, Size: 833 bytes --] Your message dated Sat, 10 Jan 2009 13:15:51 +0200 with message-id <uab9zjtso.fsf@gnu.org> and subject line Re: ^M in the info files has caused the Emacs bug report #876, regarding 23.0.60; ^M throughout Viper manual to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com immediately.) -- 876: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=876 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 2761 bytes --] From: "Drew Adams" <drew.adams@oracle.com> To: <emacs-pretest-bug@gnu.org> Subject: 23.0.60; ^M throughout Viper manual Date: Fri, 31 Oct 2008 08:56:56 -0700 Message-ID: <001a01c93b71$4d792ce0$0200a8c0@us.oracle.com> Subject line says it all In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-10-09 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' [-- Attachment #3: Type: message/rfc822, Size: 3682 bytes --] From: Eli Zaretskii <eliz@gnu.org> To: 876-done@emacsbugs.donarmstrong.com Cc: emacs-devel@gnu.org, bug-gnu-emacs@gnu.org, emacs-pretest-bug@gnu.org Subject: Re: ^M in the info files Date: Sat, 10 Jan 2009 13:15:51 +0200 Message-ID: <uab9zjtso.fsf@gnu.org> > Date: Sat, 29 Nov 2008 00:39:27 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: lekktu@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, > handa@m17n.org > > > From: "Drew Adams" <drew.adams@oracle.com> > > Date: Fri, 28 Nov 2008 13:28:34 -0800 > > Cc: 'Juanma Barranquero' <lekktu@gmail.com>, emacs-devel@gnu.org > > > > Whatever happened to this thread and the associated bugs: #876, #1117, #1284? > > > > It sounds like there were alternative proposals about how to fix this, but there > > was no discussion to try to reach a consensus or a decision. Is that where > > things were left? > > > > Meanwhile, it's still impossible to use the index in Info manuals on Windows, > > and it's impossible to use some manuals (e.g. Viper) at all. > > Don't worry, this will get fixed before Emacs 23 is ready for release. > > I will work on it soon if no one beats me to it. (Fore some value of "soon", sorry.) I fixed this bug. There were two suggestions for how to fix this: one by Handa-san in this message: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00293.html followed by a tentative patch by Juanma here: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00316.html The other suggestion was by Stefan: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00373.html I decided I liked the first alternative better, since it has much more local effect than the other one. What Stefan suggested implied messing with coding priorities, and I didn't feel that was TRT at this late stage in Emacs 23.1 development. The changes I installed are more thorough than what Juanma posted: they change both detect_coding and detect_coding_system, and also bind inhibit-null-byte-detection in a couple more places in info.el. The result was tested on GNU/Linux, MS-Windows, and MS-DOS, both with compressed and uncompressed Info files, with auto-compression-mode both on and off. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1816: 23.0.60; ^M in CC mode manual. @ 2009-01-07 11:55 ` Matzi Kratzi 2009-01-07 14:05 ` Jason Rumney 2009-01-10 11:25 ` bug#1816: marked as done (23.0.60; ^M in CC mode manual.) Emacs bug Tracking System 0 siblings, 2 replies; 74+ messages in thread From: Matzi Kratzi @ 2009-01-07 11:55 UTC (permalink / raw To: emacs-pretest-bug Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: All (probably most) lines in the CC Mode info manual are ended with ^M. I use a build from Lennart Borgman. 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:/Download/emacs-090104/emacs/etc/DEBUG for instructions. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.0.2195) of 2009-01-04 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.0.2195 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' 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: SVE value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: which-function-mode: t show-paren-mode: t iswitchb-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-h i C-s l i b m <return> <return> SPC u u <up> <return> SPC SPC SPC SPC u u u <up> <return> u <up> <up> <up> <up> <up> <return> u C-s c c - m o <backspace> <backspace> <backspace> SPC m o <backspace> <backspace> <backspace> C-s M-< C-s C-s <return> <return> M-x c o m p <backspace> <backspace> <backspace> <backspace> r e p o r t SPC e m a SPC SPC <return> Recent messages: Info-extract-pointer: Node has no Up uncompressing gv.info.gz...done uncompressing gv.info.gz...done uncompressing gv.info.gz...done uncompressing cygwin-ug-net.info.gz...done uncompressing cygwin-ug-net.info.gz...done uncompressing cygwin-ug-net.info.gz...done Mark saved where search started Mark set Mark saved where search started ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1816: 23.0.60; ^M in CC mode manual. 2009-01-07 11:55 ` bug#1816: 23.0.60; ^M in CC mode manual Matzi Kratzi @ 2009-01-07 14:05 ` Jason Rumney 2009-01-07 14:15 ` Processed: " Emacs bug Tracking System 2009-01-10 11:25 ` bug#1816: marked as done (23.0.60; ^M in CC mode manual.) Emacs bug Tracking System 1 sibling, 1 reply; 74+ messages in thread From: Jason Rumney @ 2009-01-07 14:05 UTC (permalink / raw To: Matzi Kratzi, 1816 merge 876 1816 thanks Matzi Kratzi wrote: > All (probably most) lines in the CC Mode info manual are ended with ^M. > I use a build from Lennart Borgman. > This is a known bug affecting Emacs on Windows. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Processed: Re: bug#1816: 23.0.60; ^M in CC mode manual. 2009-01-07 14:05 ` Jason Rumney @ 2009-01-07 14:15 ` Emacs bug Tracking System 0 siblings, 0 replies; 74+ messages in thread From: Emacs bug Tracking System @ 2009-01-07 14:15 UTC (permalink / raw To: Jason Rumney; +Cc: Emacs Bugs, w32 for {1816, 1284, 1117, 876} Processing commands for control@emacsbugs.donarmstrong.com: > merge 876 1816 bug#876: ^M in some Windows info files because of null-byte detection bug#1816: 23.0.60; ^M in CC mode manual. bug#1117: 23.0.60; Index in Elisp manual has ^M at the end of each line bug#1284: 23.0.60; ^M throughout Viper manual Warning: Unknown package 'w32' Warning: Unknown package 'w32' Warning: Unknown package 'w32' Warning: Unknown package 'w32' Merged 876 1117 1284 1816. > thanks Stopping processing here. Please contact me if you need assistance. Don Armstrong (administrator, Emacs bugs database) ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#1816: marked as done (23.0.60; ^M in CC mode manual.) 2009-01-07 11:55 ` bug#1816: 23.0.60; ^M in CC mode manual Matzi Kratzi 2009-01-07 14:05 ` Jason Rumney @ 2009-01-10 11:25 ` Emacs bug Tracking System 1 sibling, 0 replies; 74+ messages in thread From: Emacs bug Tracking System @ 2009-01-10 11:25 UTC (permalink / raw To: Eli Zaretskii [-- Attachment #1: Type: text/plain, Size: 828 bytes --] Your message dated Sat, 10 Jan 2009 13:15:51 +0200 with message-id <uab9zjtso.fsf@gnu.org> and subject line Re: ^M in the info files has caused the Emacs bug report #876, regarding 23.0.60; ^M in CC mode manual. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com immediately.) -- 876: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=876 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 5435 bytes --] From: "Matzi Kratzi" <matzikratzi@gmail.com> To: emacs-pretest-bug@gnu.org Subject: 23.0.60; ^M in CC mode manual. Date: Wed, 7 Jan 2009 12:55:44 +0100 Message-ID: <7f9b11c90901070355x3842939fo31e7725bc0989b43@mail.gmail.com> Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: All (probably most) lines in the CC Mode info manual are ended with ^M. I use a build from Lennart Borgman. 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:/Download/emacs-090104/emacs/etc/DEBUG for instructions. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.0.2195) of 2009-01-04 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.0.2195 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' 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: SVE value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: which-function-mode: t show-paren-mode: t iswitchb-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-h i C-s l i b m <return> <return> SPC u u <up> <return> SPC SPC SPC SPC u u u <up> <return> u <up> <up> <up> <up> <up> <return> u C-s c c - m o <backspace> <backspace> <backspace> SPC m o <backspace> <backspace> <backspace> C-s M-< C-s C-s <return> <return> M-x c o m p <backspace> <backspace> <backspace> <backspace> r e p o r t SPC e m a SPC SPC <return> Recent messages: Info-extract-pointer: Node has no Up uncompressing gv.info.gz...done uncompressing gv.info.gz...done uncompressing gv.info.gz...done uncompressing cygwin-ug-net.info.gz...done uncompressing cygwin-ug-net.info.gz...done uncompressing cygwin-ug-net.info.gz...done Mark saved where search started Mark set Mark saved where search started [-- Attachment #3: Type: message/rfc822, Size: 3682 bytes --] From: Eli Zaretskii <eliz@gnu.org> To: 876-done@emacsbugs.donarmstrong.com Cc: emacs-devel@gnu.org, bug-gnu-emacs@gnu.org, emacs-pretest-bug@gnu.org Subject: Re: ^M in the info files Date: Sat, 10 Jan 2009 13:15:51 +0200 Message-ID: <uab9zjtso.fsf@gnu.org> > Date: Sat, 29 Nov 2008 00:39:27 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: lekktu@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, > handa@m17n.org > > > From: "Drew Adams" <drew.adams@oracle.com> > > Date: Fri, 28 Nov 2008 13:28:34 -0800 > > Cc: 'Juanma Barranquero' <lekktu@gmail.com>, emacs-devel@gnu.org > > > > Whatever happened to this thread and the associated bugs: #876, #1117, #1284? > > > > It sounds like there were alternative proposals about how to fix this, but there > > was no discussion to try to reach a consensus or a decision. Is that where > > things were left? > > > > Meanwhile, it's still impossible to use the index in Info manuals on Windows, > > and it's impossible to use some manuals (e.g. Viper) at all. > > Don't worry, this will get fixed before Emacs 23 is ready for release. > > I will work on it soon if no one beats me to it. (Fore some value of "soon", sorry.) I fixed this bug. There were two suggestions for how to fix this: one by Handa-san in this message: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00293.html followed by a tentative patch by Juanma here: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00316.html The other suggestion was by Stefan: http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00373.html I decided I liked the first alternative better, since it has much more local effect than the other one. What Stefan suggested implied messing with coding priorities, and I didn't feel that was TRT at this late stage in Emacs 23.1 development. The changes I installed are more thorough than what Juanma posted: they change both detect_coding and detect_coding_system, and also bind inhibit-null-byte-detection in a couple more places in info.el. The result was tested on GNU/Linux, MS-Windows, and MS-DOS, both with compressed and uncompressed Info files, with auto-compression-mode both on and off. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 11:15 ` Eli Zaretskii ` (3 preceding siblings ...) 2009-01-07 11:55 ` bug#1816: 23.0.60; ^M in CC mode manual Matzi Kratzi @ 2009-01-10 12:14 ` Eli Zaretskii 2009-01-12 20:56 ` Stefan Monnier 2009-01-10 14:07 ` Juanma Barranquero ` (2 subsequent siblings) 7 siblings, 1 reply; 74+ messages in thread From: Eli Zaretskii @ 2009-01-10 12:14 UTC (permalink / raw To: Kenichi Handa; +Cc: emacs-devel > Date: Sat, 10 Jan 2009 13:15:51 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-pretest-bug@gnu.org, bug-gnu-emacs@gnu.org, emacs-devel@gnu.org > > The changes I installed are more thorough than what Juanma posted: > they change both detect_coding and detect_coding_system, and also bind > inhibit-null-byte-detection in a couple more places in info.el. When documenting the new option, I found a strange inconsistency between detect-coding-region/string and coding detection by insert-file-contents. If null bytes are detected, detect_coding sets up to use no-conversion, but detect-coding-region/string does not call detect_coding. Instead, detect-coding-region/string call detect_coding_system, which does not return no-conversion for a region or string that include null bytes. insert-file-contents does use no-conversion for files that contain null bytes, but it does so because decode_coding_gap does call detect_coding. This creates an inconsistency for Lisp programs that do their own decoding: if they call detect-coding-region/string for a region or string with null bytes, they will not see no-conversion in the return value, but insert-file-contents will use no-conversion nonetheless. I think this inconsistency constitutes a bug. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 12:14 ` ^M in the info files Eli Zaretskii @ 2009-01-12 20:56 ` Stefan Monnier 2009-01-12 22:04 ` Eli Zaretskii 0 siblings, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2009-01-12 20:56 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel, Kenichi Handa > When documenting the new option, I found a strange inconsistency > between detect-coding-region/string and coding detection by > insert-file-contents. If null bytes are detected, detect_coding sets > up to use no-conversion, but detect-coding-region/string does not call > detect_coding. Instead, detect-coding-region/string call > detect_coding_system, which does not return no-conversion for a region > or string that include null bytes. insert-file-contents does use > no-conversion for files that contain null bytes, but it does so > because decode_coding_gap does call detect_coding. > This creates an inconsistency for Lisp programs that do their own > decoding: if they call detect-coding-region/string for a region or > string with null bytes, they will not see no-conversion in the return > value, but insert-file-contents will use no-conversion nonetheless. > I think this inconsistency constitutes a bug. Indeed, it sounds like a bug. Not sure how/when it would manifest itself, tho. Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-12 20:56 ` Stefan Monnier @ 2009-01-12 22:04 ` Eli Zaretskii 0 siblings, 0 replies; 74+ messages in thread From: Eli Zaretskii @ 2009-01-12 22:04 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-devel, handa > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Kenichi Handa <handa@m17n.org>, emacs-devel@gnu.org > Date: Mon, 12 Jan 2009 15:56:16 -0500 > > > This creates an inconsistency for Lisp programs that do their own > > decoding: if they call detect-coding-region/string for a region or > > string with null bytes, they will not see no-conversion in the return > > value, but insert-file-contents will use no-conversion nonetheless. > > > I think this inconsistency constitutes a bug. > > Indeed, it sounds like a bug. Not sure how/when it would manifest > itself, tho. Well, for starters, it means that insert-file-contents does its own detection that cannot be separated from it on the Lisp level. That is, (let ((coding-system-for-read 'undecided)) (insert-file-contents FOO)) and (insert-file-contents-literally FOO) (let ((coding-system-for-read (detect-coding-region (point-min) (point-max) t))) (insert-file-contents FOO)) will surprisingly produce different results. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 11:15 ` Eli Zaretskii ` (4 preceding siblings ...) 2009-01-10 12:14 ` ^M in the info files Eli Zaretskii @ 2009-01-10 14:07 ` Juanma Barranquero 2009-01-10 15:13 ` Eli Zaretskii 2009-01-10 16:21 ` Drew Adams 2009-01-12 20:54 ` Stefan Monnier 7 siblings, 1 reply; 74+ messages in thread From: Juanma Barranquero @ 2009-01-10 14:07 UTC (permalink / raw To: Eli Zaretskii; +Cc: 876-done, emacs-devel On Sat, Jan 10, 2009 at 12:15, Eli Zaretskii <eliz@gnu.org> wrote: > I fixed this bug. If the info files are compressed with gzip (using the Windows binary from http://www.gzip.org), when visited from Info they still have spurious ^M. As an aside, when I use MSYS' gzip I get an error in decompressing: Error while executing "gzip -c -q -d < c:/emacs/info/efaq.gz" gzip: stdin: invalid compressed data--crc error Could be related to CRLF issues in the redirection (but this is a gzip problem, not Emacs', of course). Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 14:07 ` Juanma Barranquero @ 2009-01-10 15:13 ` Eli Zaretskii 2009-01-10 18:23 ` Juanma Barranquero 0 siblings, 1 reply; 74+ messages in thread From: Eli Zaretskii @ 2009-01-10 15:13 UTC (permalink / raw To: Juanma Barranquero; +Cc: 876-done, emacs-devel > Date: Sat, 10 Jan 2009 15:07:37 +0100 > From: "Juanma Barranquero" <lekktu@gmail.com> > Cc: 876-done@emacsbugs.donarmstrong.com, emacs-devel@gnu.org > > On Sat, Jan 10, 2009 at 12:15, Eli Zaretskii <eliz@gnu.org> wrote: > > > I fixed this bug. > > If the info files are compressed with gzip (using the Windows binary > from http://www.gzip.org), when visited from Info they still have > spurious ^M. I cannot reproduce this (tried with compressing info/emacs*). Please send a complete self-contained recipe. Does "spurious" mean that every line has a ^M, like you saw before the fix, or just some lines? Also, does the above reference to http://www.gzip.org means that files compressed by other versions of gzip do work as intended? > As an aside, when I use MSYS' gzip I get an error in decompressing: > > Error while executing "gzip -c -q -d < c:/emacs/info/efaq.gz" > gzip: stdin: invalid compressed data--crc error > > Could be related to CRLF issues in the redirection (but this is a gzip > problem, not Emacs', of course). Right, and I don't have MSYS anyway. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 15:13 ` Eli Zaretskii @ 2009-01-10 18:23 ` Juanma Barranquero 2009-01-10 19:08 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 74+ messages in thread From: Juanma Barranquero @ 2009-01-10 18:23 UTC (permalink / raw To: Eli Zaretskii; +Cc: 876-done, emacs-devel On Sat, Jan 10, 2009 at 16:13, Eli Zaretskii <eliz@gnu.org> wrote: > I cannot reproduce this (tried with compressing info/emacs*). Please > send a complete self-contained recipe. Sorry, apparently it depends on something in my .emacs. It's still a bug, though. Try with cd info gzip efaq emacs -Q -eval "(progn (set-language-environment \"UTF-8\") (info \"(efaq)Top\"))" > Does "spurious" mean that every line has a ^M, like you saw before the > fix, or just some lines? Every line, just like before the fix. > Also, does the above reference to http://www.gzip.org means that files > compressed by other versions of gzip do work as intended? Means that using the gzip from www.gzip.org it fails, and using the one from MSYS I get the error I reported. I don't have other versions of gzip. For additional fun, cd info gzip emacs emacs -Q -eval "(info \"(emacs)Top\")" => gzip: illegal option -- Q usage: gzip [-acdfhlLnNrtvV19] [-S suffix] [file ... (this with the standard www.gzip.org version). Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 18:23 ` Juanma Barranquero @ 2009-01-10 19:08 ` Eli Zaretskii 2009-01-10 19:12 ` Eli Zaretskii 2009-01-10 19:19 ` Eli Zaretskii 2 siblings, 0 replies; 74+ messages in thread From: Eli Zaretskii @ 2009-01-10 19:08 UTC (permalink / raw To: Juanma Barranquero; +Cc: 876-done, emacs-devel ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 18:23 ` Juanma Barranquero 2009-01-10 19:08 ` Eli Zaretskii @ 2009-01-10 19:12 ` Eli Zaretskii 2009-01-10 19:19 ` Eli Zaretskii 2 siblings, 0 replies; 74+ messages in thread From: Eli Zaretskii @ 2009-01-10 19:12 UTC (permalink / raw To: Juanma Barranquero; +Cc: 876-done, emacs-devel > Date: Sat, 10 Jan 2009 19:23:28 +0100 > From: "Juanma Barranquero" <lekktu@gmail.com> > Cc: 876-done@emacsbugs.donarmstrong.com, emacs-devel@gnu.org > > On Sat, Jan 10, 2009 at 16:13, Eli Zaretskii <eliz@gnu.org> wrote: > > > I cannot reproduce this (tried with compressing info/emacs*). Please > > send a complete self-contained recipe. > > Sorry, apparently it depends on something in my .emacs. It's still a > bug, though. > > Try with > > cd info > gzip efaq > emacs -Q -eval "(progn (set-language-environment \"UTF-8\") (info \"(efaq)Top\"))" Yes, I see that now, but it has something to do with UTF-8 as the language environment (it works correctly without it). The Info buffer has utf-8-unix as its buffer-file-coding-system, which is another sign. So I think this is a separate bug. Please file a separate bug report for it. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 18:23 ` Juanma Barranquero 2009-01-10 19:08 ` Eli Zaretskii 2009-01-10 19:12 ` Eli Zaretskii @ 2009-01-10 19:19 ` Eli Zaretskii 2009-01-10 21:04 ` Juanma Barranquero 2 siblings, 1 reply; 74+ messages in thread From: Eli Zaretskii @ 2009-01-10 19:19 UTC (permalink / raw To: Juanma Barranquero; +Cc: 876-done, emacs-devel > Date: Sat, 10 Jan 2009 19:23:28 +0100 > From: "Juanma Barranquero" <lekktu@gmail.com> > Cc: 876-done@emacsbugs.donarmstrong.com, emacs-devel@gnu.org > > cd info > gzip emacs > emacs -Q -eval "(info \"(emacs)Top\")" > => > gzip: illegal option -- Q > usage: gzip [-acdfhlLnNrtvV19] [-S suffix] [file ... > > (this with the standard www.gzip.org version). Doesn't happen to me, neither with gzip 1.2.4 from gzip.org, nor with v1.3.5 from GnuWin32. I did replace "emacs" with a full file name, though, to make sure it doesn't pick up some other version somewhere on my INFOPATH. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 19:19 ` Eli Zaretskii @ 2009-01-10 21:04 ` Juanma Barranquero 0 siblings, 0 replies; 74+ messages in thread From: Juanma Barranquero @ 2009-01-10 21:04 UTC (permalink / raw To: Eli Zaretskii; +Cc: 876-done, emacs-devel On Sat, Jan 10, 2009 at 20:19, Eli Zaretskii <eliz@gnu.org> wrote: >> gzip: illegal option -- Q >> usage: gzip [-acdfhlLnNrtvV19] [-S suffix] [file ... >> >> (this with the standard www.gzip.org version). My mistake. My command interpreter was trying to execute emacs.gz. Sorry for the noise. Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
* RE: ^M in the info files 2009-01-10 11:15 ` Eli Zaretskii ` (5 preceding siblings ...) 2009-01-10 14:07 ` Juanma Barranquero @ 2009-01-10 16:21 ` Drew Adams [not found] ` <handler.1845.B.12316045139313.ack@emacsbugs.donarmstrong.com> 2009-01-10 23:16 ` ^M in the info files Lennart Borgman 2009-01-12 20:54 ` Stefan Monnier 7 siblings, 2 replies; 74+ messages in thread From: Drew Adams @ 2009-01-10 16:21 UTC (permalink / raw To: 'Eli Zaretskii', 876-done Cc: emacs-pretest-bug, bug-gnu-emacs, emacs-devel Thanks for fixing this. ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <handler.1845.B.12316045139313.ack@emacsbugs.donarmstrong.com>]
* bug#1845: Acknowledgement (^M in the info files) [not found] ` <handler.1845.B.12316045139313.ack@emacsbugs.donarmstrong.com> @ 2009-01-10 17:11 ` Drew Adams 0 siblings, 0 replies; 74+ messages in thread From: Drew Adams @ 2009-01-10 17:11 UTC (permalink / raw To: 1845, owner Something wrong here, it seems. I received this ack, and another one (identical) for new bug #1844. I filed no such new bugs. I simply replied (once) to Eli's message saying that he had fixed bug #876, by saying thank you. The bug tracker seems to be inebriated again. Also, I've recently received acks apparently intended for others, with no connection to any bug ever filed by me or any mail ever sent by me. I assume that others have also received such spurious acks. > From: Emacs bug Tracking System [mailto:owner@emacsbugs.donarmstrong.com] > Sent: Saturday, January 10, 2009 8:30 AM > To: Drew Adams > Subject: bug#1845: Acknowledgement (^M in the info files) > > > Thank you for filing a new bug report with Emacs. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Emacs Bugs <bug-gnu-emacs@gnu.org> > > If you wish to submit further information on this problem, please > send it to 1845@emacsbugs.donarmstrong.com, as before. > > Please do not send mail to owner@emacsbugs.donarmstrong.com > unless you wish to report a problem with the Bug-tracking system. > > -- > 1845: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1845 > Emacs Bug Tracking System > Contact owner@emacsbugs.donarmstrong.com with problems ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 16:21 ` Drew Adams [not found] ` <handler.1845.B.12316045139313.ack@emacsbugs.donarmstrong.com> @ 2009-01-10 23:16 ` Lennart Borgman 2009-01-11 5:41 ` dhruva 2009-01-11 5:51 ` dhruva 1 sibling, 2 replies; 74+ messages in thread From: Lennart Borgman @ 2009-01-10 23:16 UTC (permalink / raw To: Eli Zaretskii; +Cc: Emacs Devel On Sat, Jan 10, 2009 at 5:21 PM, Drew Adams <drew.adams@oracle.com> wrote: > Thanks for fixing this. Yes, great Eli! ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 23:16 ` ^M in the info files Lennart Borgman @ 2009-01-11 5:41 ` dhruva 2009-01-11 5:51 ` dhruva 1 sibling, 0 replies; 74+ messages in thread From: dhruva @ 2009-01-11 5:41 UTC (permalink / raw To: Lennart Borgman; +Cc: Eli Zaretskii, Emacs Devel Hello, On Sun, Jan 11, 2009 at 4:46 AM, Lennart Borgman <lennart.borgman@gmail.com> wrote: > On Sat, Jan 10, 2009 at 5:21 PM, Drew Adams <drew.adams@oracle.com> wrote: >> Thanks for fixing this. > > Yes, great Eli! I start emacs 'emacs -q' (built using MinGW on WXP, bzr HEAD) and see ^M in ada-mode. Do I need to 'bootstrap' or should a normal 'make all install'. -dhruva -- Contents reflect my personal views only! ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 23:16 ` ^M in the info files Lennart Borgman 2009-01-11 5:41 ` dhruva @ 2009-01-11 5:51 ` dhruva 1 sibling, 0 replies; 74+ messages in thread From: dhruva @ 2009-01-11 5:51 UTC (permalink / raw To: Eli Zaretskii; +Cc: Emacs Devel Hello, On Sun, Jan 11, 2009 at 4:46 AM, Lennart Borgman <lennart.borgman@gmail.com> wrote: > On Sat, Jan 10, 2009 at 5:21 PM, Drew Adams <drew.adams@oracle.com> wrote: >> Thanks for fixing this. > > Yes, great Eli! I had to do a 'make clean' and 'make all install' (on WXP using MinGW, bzr HEAD) to get it working. Thanks for the fix! -dhruva -- Contents reflect my personal views only! ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-10 11:15 ` Eli Zaretskii ` (6 preceding siblings ...) 2009-01-10 16:21 ` Drew Adams @ 2009-01-12 20:54 ` Stefan Monnier 2009-01-12 22:13 ` Eli Zaretskii 7 siblings, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2009-01-12 20:54 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-pretest-bug, bug-gnu-emacs, 876-done, emacs-devel Thank you, Eli, > I decided I liked the first alternative better, since it has much > more local effect than the other one. What Stefan suggested implied > messing with coding priorities, and I didn't feel that was TRT at this > late stage in Emacs 23.1 development. [ Obviously my suggestion requires more work to implement, but.. ] Hmm...curious, why does it involve coding priorities? Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-12 20:54 ` Stefan Monnier @ 2009-01-12 22:13 ` Eli Zaretskii 2009-01-12 22:27 ` Glenn Morris 2009-01-12 22:27 ` Glenn Morris 0 siblings, 2 replies; 74+ messages in thread From: Eli Zaretskii @ 2009-01-12 22:13 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-pretest-bug, bug-gnu-emacs, 876-done, emacs-devel > X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, > FORGED_RCVD_HELO,SPF_SOFTFAIL autolearn=no version=3.1.0 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: 876-done@emacsbugs.donarmstrong.com, emacs-pretest-bug@gnu.org, bug-gnu-emacs@gnu.org, emacs-devel@gnu.org > Date: Mon, 12 Jan 2009 15:54:38 -0500 > > Hmm...curious, why does it involve coding priorities? You suggested to introduce a way of controlling which possible encodings will _not_ be acceptable by the caller of detect-coding-region/string. These primitives work by scanning the coding_priorities[] array and checking them against those categories that has been rejected based on the text in the region/string. See detect_coding and detect_coding_system. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-12 22:13 ` Eli Zaretskii @ 2009-01-12 22:27 ` Glenn Morris 2009-01-13 4:01 ` Eli Zaretskii 2009-01-13 4:01 ` bug#876: ^M in the info files Eli Zaretskii 2009-01-12 22:27 ` Glenn Morris 1 sibling, 2 replies; 74+ messages in thread From: Glenn Morris @ 2009-01-12 22:27 UTC (permalink / raw To: Eli Zaretskii; +Cc: Stefan Monnier, 876, emacs-devel Please stop cc'ing emacs-pretest-bug@gnu.org and bug-gnu-emacs@gnu.org in this discussion, it messes up the bug tracker. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: ^M in the info files 2009-01-12 22:27 ` Glenn Morris @ 2009-01-13 4:01 ` Eli Zaretskii 2009-01-13 4:24 ` bug bugs [was Re: ^M in the info files] Glenn Morris 2009-01-13 4:01 ` bug#876: ^M in the info files Eli Zaretskii 1 sibling, 1 reply; 74+ messages in thread From: Eli Zaretskii @ 2009-01-13 4:01 UTC (permalink / raw To: Glenn Morris; +Cc: monnier, 876, emacs-devel > From: Glenn Morris <rgm@gnu.org> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 876@emacsbugs.donarmstrong.com, emacs-devel@gnu.org > Date: Mon, 12 Jan 2009 17:27:03 -0500 > > > Please stop cc'ing emacs-pretest-bug@gnu.org and bug-gnu-emacs@gnu.org > in this discussion, it messes up the bug tracker. Why won't the tracker get its act together and stop forcing us into editing mail headers? I use the Rmail's `r' command, which replies to all the original "To" and "CC" addressees. With the amounts of mail I'm responding to, I cannot afford editing headers of every message I send. Even if I try, I will surely sometimes forget. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug bugs [was Re: ^M in the info files] 2009-01-13 4:01 ` Eli Zaretskii @ 2009-01-13 4:24 ` Glenn Morris 2009-01-13 18:56 ` Eli Zaretskii 0 siblings, 1 reply; 74+ messages in thread From: Glenn Morris @ 2009-01-13 4:24 UTC (permalink / raw To: Eli Zaretskii; +Cc: monnier, emacs-devel Eli Zaretskii wrote: > Why won't the tracker get its act together and stop forcing us into > editing mail headers? It's been asked for repeatedly, but it doesn't happen. There seems no point even discussing it, all the points have been made. I know people shouldn't have to make this effort with headers, but I was only asking. I'm fed up of duplicate and triplicate mails, and large numbers of bogus bug reports that need merging. > I use the Rmail's `r' command, which replies to all the original > "To" and "CC" addressees. I don't use rmail, but rmail-dont-reply-to-names ...? ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: bug bugs [was Re: ^M in the info files] 2009-01-13 4:24 ` bug bugs [was Re: ^M in the info files] Glenn Morris @ 2009-01-13 18:56 ` Eli Zaretskii 2009-01-13 20:50 ` bug bugs Glenn Morris 0 siblings, 1 reply; 74+ messages in thread From: Eli Zaretskii @ 2009-01-13 18:56 UTC (permalink / raw To: Glenn Morris; +Cc: monnier, emacs-devel > From: Glenn Morris <rgm@gnu.org> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Mon, 12 Jan 2009 23:24:35 -0500 > > rmail-dont-reply-to-names ...? Sure, but I cannot use rmail-dont-reply-to-names in this case, I think, since it means I will never reply to these mailing lists, even if the message didn't come from the bug tracker. Those lists aren't yet usurped by the bug tracker, are they? People can still post there without their messages being taken as bug reports, can't they? ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: bug bugs 2009-01-13 18:56 ` Eli Zaretskii @ 2009-01-13 20:50 ` Glenn Morris 2009-01-14 4:12 ` Eli Zaretskii 0 siblings, 1 reply; 74+ messages in thread From: Glenn Morris @ 2009-01-13 20:50 UTC (permalink / raw To: Eli Zaretskii; +Cc: monnier, emacs-devel Eli Zaretskii wrote: > Those lists aren't yet usurped by the bug tracker, are they? Yes they are. (There is no longer "lists" plural either, they are identical.) > People can still post there without their messages being taken as > bug reports, can't they? No. (Well, except for bug#936, the broken newsgroup gateway.) ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: bug bugs 2009-01-13 20:50 ` bug bugs Glenn Morris @ 2009-01-14 4:12 ` Eli Zaretskii 2009-01-14 13:45 ` Chong Yidong 2009-01-14 19:40 ` Glenn Morris 0 siblings, 2 replies; 74+ messages in thread From: Eli Zaretskii @ 2009-01-14 4:12 UTC (permalink / raw To: Glenn Morris; +Cc: monnier, emacs-devel > From: Glenn Morris <rgm@gnu.org> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Tue, 13 Jan 2009 15:50:16 -0500 > > Eli Zaretskii wrote: > > > Those lists aren't yet usurped by the bug tracker, are they? > > Yes they are. So where do humans have chance of talking about bugs? ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: bug bugs 2009-01-14 4:12 ` Eli Zaretskii @ 2009-01-14 13:45 ` Chong Yidong 2009-01-14 19:13 ` Eli Zaretskii 2009-01-14 19:40 ` Glenn Morris 1 sibling, 1 reply; 74+ messages in thread From: Chong Yidong @ 2009-01-14 13:45 UTC (permalink / raw To: Eli Zaretskii; +Cc: Glenn Morris, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > So where do humans have chance of talking about bugs? Send a CC to NNNN@emacsbugs.donarmstrong.com, where NNNN is the bug number, instead of bug-gnu-emacs@gnu.org; these will show up on the mailing list too. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: bug bugs 2009-01-14 13:45 ` Chong Yidong @ 2009-01-14 19:13 ` Eli Zaretskii 2009-01-15 0:30 ` Stephen J. Turnbull 0 siblings, 1 reply; 74+ messages in thread From: Eli Zaretskii @ 2009-01-14 19:13 UTC (permalink / raw To: Chong Yidong; +Cc: rgm, monnier, emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Cc: Glenn Morris <rgm@gnu.org>, monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Wed, 14 Jan 2009 08:45:28 -0500 > > Eli Zaretskii <eliz@gnu.org> writes: > > > So where do humans have chance of talking about bugs? > > Send a CC to NNNN@emacsbugs.donarmstrong.com, where NNNN is the bug > number, instead of bug-gnu-emacs@gnu.org; these will show up on the > mailing list too. Are you saying that if I want to talk to you about bugs, I need to do that via the bug tracker? I find that a bit silly. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: bug bugs 2009-01-14 19:13 ` Eli Zaretskii @ 2009-01-15 0:30 ` Stephen J. Turnbull 0 siblings, 0 replies; 74+ messages in thread From: Stephen J. Turnbull @ 2009-01-15 0:30 UTC (permalink / raw To: Eli Zaretskii; +Cc: Chong Yidong, monnier, emacs-devel Eli Zaretskii writes: > Are you saying that if I want to talk to you about bugs, I need to do > that via the bug tracker? I find that a bit silly. That's not "silly", that's "process". The intent is that useful information be located where it is most likely to be used, and found in the future. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: bug bugs 2009-01-14 4:12 ` Eli Zaretskii 2009-01-14 13:45 ` Chong Yidong @ 2009-01-14 19:40 ` Glenn Morris 1 sibling, 0 replies; 74+ messages in thread From: Glenn Morris @ 2009-01-14 19:40 UTC (permalink / raw To: Eli Zaretskii; +Cc: monnier, emacs-devel Eli Zaretskii wrote: > So where do humans have chance of talking about bugs? That's somewhat off my topic. I simply want to assure you that the the _only_ reason to send mail to bug-gnu-emacs or emacs-pretest-bug is to create a new bug in the tracker. It's been that way for months and months. Those addresses should never be appearing in replies. At best, it creates pointless duplicate mails; at worst it creates new, separate bug reports that need to be tidied up. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#876: ^M in the info files 2009-01-12 22:27 ` Glenn Morris 2009-01-13 4:01 ` Eli Zaretskii @ 2009-01-13 4:01 ` Eli Zaretskii 1 sibling, 0 replies; 74+ messages in thread From: Eli Zaretskii @ 2009-01-13 4:01 UTC (permalink / raw To: Glenn Morris; +Cc: 876, emacs-devel > From: Glenn Morris <rgm@gnu.org> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 876@emacsbugs.donarmstrong.com, emacs-devel@gnu.org > Date: Mon, 12 Jan 2009 17:27:03 -0500 > > > Please stop cc'ing emacs-pretest-bug@gnu.org and bug-gnu-emacs@gnu.org > in this discussion, it messes up the bug tracker. Why won't the tracker get its act together and stop forcing us into editing mail headers? I use the Rmail's `r' command, which replies to all the original "To" and "CC" addressees. With the amounts of mail I'm responding to, I cannot afford editing headers of every message I send. Even if I try, I will surely sometimes forget. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#876: ^M in the info files 2009-01-12 22:13 ` Eli Zaretskii 2009-01-12 22:27 ` Glenn Morris @ 2009-01-12 22:27 ` Glenn Morris 1 sibling, 0 replies; 74+ messages in thread From: Glenn Morris @ 2009-01-12 22:27 UTC (permalink / raw To: Eli Zaretskii; +Cc: 876, emacs-devel Please stop cc'ing emacs-pretest-bug@gnu.org and bug-gnu-emacs@gnu.org in this discussion, it messes up the bug tracker. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: A few bugs not in the bug tracker (I think) 2008-08-06 12:31 ` Kenichi Handa 2008-08-06 13:14 ` Juanma Barranquero @ 2008-08-06 18:04 ` Eli Zaretskii 1 sibling, 0 replies; 74+ messages in thread From: Eli Zaretskii @ 2008-08-06 18:04 UTC (permalink / raw To: Kenichi Handa; +Cc: lekktu, emacs-devel > From: Kenichi Handa <handa@m17n.org> > Date: Wed, 06 Aug 2008 21:31:51 +0900 > Cc: emacs-devel@gnu.org > > > - ^M in the info files [Windows] > > http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00739.html > > http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00215.html > > The problem is the newly introduced null-byte detection > mechanism, but the discussion divergented to encoding of > non-ascii characters, and for the original problem of > null-byte in info file, no one replied to the question in > this mail: > http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00225.html I think the best solution would be that Emacs never tries to detect whether Info files are binary. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: A few bugs not in the bug tracker (I think) 2008-08-06 11:09 A few bugs not in the bug tracker (I think) Juanma Barranquero 2008-08-06 12:31 ` Kenichi Handa @ 2008-08-06 13:35 ` Don Armstrong 2008-08-06 13:38 ` Juanma Barranquero 1 sibling, 1 reply; 74+ messages in thread From: Don Armstrong @ 2008-08-06 13:35 UTC (permalink / raw To: emacs-devel On Wed, 06 Aug 2008, Juanma Barranquero wrote: > BTW, how do you know whether a bug has already been reported, other > than perusing the open bug list? I see ways to search by bug #, > package, maintainer e-mail, severity, tag, etc., but not a text > search in the body of the messages (or even the subject). http://www.google.com/search?q=site%3Aemacsbugs.donarmstrong.com%20bytecode for example, will search. There is also a full-text search engine, but I haven't deployed it yet for emacs bugs. [I want to move things over before I do that, but I'm currently at Debconf working on debbugs enhancements, and haven't had a chance to do that.] Don Armstrong -- "The trouble with you, Ibid" he said, "is that you think you're the biggest bloody authority on everything" -- Terry Pratchet _Pyramids_ p146 http://www.donarmstrong.com http://rzlab.ucr.edu ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: A few bugs not in the bug tracker (I think) 2008-08-06 13:35 ` Don Armstrong @ 2008-08-06 13:38 ` Juanma Barranquero 0 siblings, 0 replies; 74+ messages in thread From: Juanma Barranquero @ 2008-08-06 13:38 UTC (permalink / raw To: emacs-devel On Wed, Aug 6, 2008 at 15:35, Don Armstrong <don@donarmstrong.com> wrote: > http://www.google.com/search?q=site%3Aemacsbugs.donarmstrong.com%20bytecode > > for example, will search. Ah, I hadn't thought of that. > There is also a full-text search engine, but > I haven't deployed it yet for emacs bugs. OK. Thanks, Juanma ^ permalink raw reply [flat|nested] 74+ messages in thread
end of thread, other threads:[~2009-01-15 0:30 UTC | newest] Thread overview: 74+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-08-06 11:09 A few bugs not in the bug tracker (I think) Juanma Barranquero 2008-08-06 12:31 ` Kenichi Handa 2008-08-06 13:14 ` Juanma Barranquero 2008-08-06 13:36 ` Juanma Barranquero 2008-08-07 4:25 ` Miles Bader 2008-08-07 11:26 ` Juanma Barranquero 2008-08-07 0:48 ` ^M in the info files Kenichi Handa 2008-08-07 3:20 ` Eli Zaretskii 2008-08-07 3:22 ` Juanma Barranquero 2008-08-07 3:47 ` Kenichi Handa 2008-08-07 13:01 ` Juanma Barranquero 2008-08-08 1:28 ` Kenichi Handa 2008-08-08 11:02 ` Juanma Barranquero 2008-08-13 10:08 ` Kenichi Handa 2008-08-15 23:09 ` Juanma Barranquero 2008-08-07 20:18 ` Stefan Monnier 2008-11-28 21:28 ` Drew Adams 2008-11-28 22:39 ` Eli Zaretskii 2008-11-28 22:44 ` Juanma Barranquero 2008-11-29 10:50 ` Eli Zaretskii 2008-11-29 11:56 ` Juanma Barranquero 2008-11-28 22:49 ` Drew Adams 2008-11-29 10:51 ` Eli Zaretskii 2009-01-10 11:15 ` Eli Zaretskii 2008-09-03 16:39 ` bug#876: ^M in some Windows info files because of null-byte detection Juanma Barranquero 2009-01-10 11:25 ` bug#876: marked as done (^M in some Windows info files because of null-byte detection) Emacs bug Tracking System 2008-10-08 6:49 ` bug#1117: 23.0.60; Index in Elisp manual has ^M at the end of each line Drew Adams 2008-10-08 8:02 ` Juanma Barranquero 2008-10-08 10:01 ` Eli Zaretskii 2008-10-08 16:52 ` Juanma Barranquero 2008-10-08 14:10 ` Drew Adams 2009-01-10 11:25 ` bug#1117: marked as done (23.0.60; Index in Elisp manual has ^M at the end of each line) Emacs bug Tracking System 2008-10-31 15:56 ` bug#1284: 23.0.60; ^M throughout Viper manual Drew Adams 2008-10-31 16:26 ` Drew Adams 2008-10-31 18:41 ` Eli Zaretskii 2008-10-31 16:26 ` Juanma Barranquero 2008-10-31 20:47 ` Leo 2009-01-10 11:25 ` bug#1284: marked as done (23.0.60; ^M throughout Viper manual) Emacs bug Tracking System 2009-01-07 11:55 ` bug#1816: 23.0.60; ^M in CC mode manual Matzi Kratzi 2009-01-07 14:05 ` Jason Rumney 2009-01-07 14:15 ` Processed: " Emacs bug Tracking System 2009-01-10 11:25 ` bug#1816: marked as done (23.0.60; ^M in CC mode manual.) Emacs bug Tracking System 2009-01-10 12:14 ` ^M in the info files Eli Zaretskii 2009-01-12 20:56 ` Stefan Monnier 2009-01-12 22:04 ` Eli Zaretskii 2009-01-10 14:07 ` Juanma Barranquero 2009-01-10 15:13 ` Eli Zaretskii 2009-01-10 18:23 ` Juanma Barranquero 2009-01-10 19:08 ` Eli Zaretskii 2009-01-10 19:12 ` Eli Zaretskii 2009-01-10 19:19 ` Eli Zaretskii 2009-01-10 21:04 ` Juanma Barranquero 2009-01-10 16:21 ` Drew Adams [not found] ` <handler.1845.B.12316045139313.ack@emacsbugs.donarmstrong.com> 2009-01-10 17:11 ` bug#1845: Acknowledgement (^M in the info files) Drew Adams 2009-01-10 23:16 ` ^M in the info files Lennart Borgman 2009-01-11 5:41 ` dhruva 2009-01-11 5:51 ` dhruva 2009-01-12 20:54 ` Stefan Monnier 2009-01-12 22:13 ` Eli Zaretskii 2009-01-12 22:27 ` Glenn Morris 2009-01-13 4:01 ` Eli Zaretskii 2009-01-13 4:24 ` bug bugs [was Re: ^M in the info files] Glenn Morris 2009-01-13 18:56 ` Eli Zaretskii 2009-01-13 20:50 ` bug bugs Glenn Morris 2009-01-14 4:12 ` Eli Zaretskii 2009-01-14 13:45 ` Chong Yidong 2009-01-14 19:13 ` Eli Zaretskii 2009-01-15 0:30 ` Stephen J. Turnbull 2009-01-14 19:40 ` Glenn Morris 2009-01-13 4:01 ` bug#876: ^M in the info files Eli Zaretskii 2009-01-12 22:27 ` Glenn Morris 2008-08-06 18:04 ` A few bugs not in the bug tracker (I think) Eli Zaretskii 2008-08-06 13:35 ` Don Armstrong 2008-08-06 13:38 ` Juanma Barranquero
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.