GNU bug report logs -
#17714
24.4.50; File coding system not detected correctly
Previous Next
Reported by: Jorgen Schaefer <forcer <at> forcix.cx>
Date: Fri, 6 Jun 2014 08:26:01 UTC
Severity: normal
Found in version 24.4.50
Done: Jorgen Schaefer <forcer <at> forcix.cx>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17714 in the body.
You can then email your comments to 17714 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17714
; Package
emacs
.
(Fri, 06 Jun 2014 08:26:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jorgen Schaefer <forcer <at> forcix.cx>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 06 Jun 2014 08:26:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Since a few days ago, current trunk stopped detecting file coding
systems correctly for me. For a file that is opened as utf-8 with stable
Emacs, it now says (using emacs -q, fundamental-mode):
-----
buffer-file-coding-system is a variable defined in `C source code'.
Its value is no-conversion
Local in buffer Todo; global value is utf-8-unix
-----
M-x revert-buffer-with-coding-system RET utf-8 RET works fine.
Configured using:
`configure --without-x'
Configured features:
SOUND NOTIFY LIBXML2 ZLIB
Important settings:
value of $LC_ALL:
value of $LC_COLLATE: de_DE.UTF-8
value of $LC_CTYPE: de_DE.UTF-8
value of $LC_MESSAGES: POSIX
value of $LC_MONETARY: POSIX
value of $LC_NUMERIC: POSIX
value of $LC_TIME: POSIX
value of $LANG: POSIX
locale-coding-system: utf-8-unix
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17714
; Package
emacs
.
(Fri, 06 Jun 2014 09:23:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 17714 <at> debbugs.gnu.org (full text, mbox):
> From: Jorgen Schaefer <forcer <at> forcix.cx>
> Date: Fri, 06 Jun 2014 10:24:53 +0200
>
> Since a few days ago, current trunk stopped detecting file coding
> systems correctly for me. For a file that is opened as utf-8 with stable
> Emacs, it now says (using emacs -q, fundamental-mode):
>
> -----
> buffer-file-coding-system is a variable defined in `C source code'.
> Its value is no-conversion
> Local in buffer Todo; global value is utf-8-unix
> -----
>
> M-x revert-buffer-with-coding-system RET utf-8 RET works fine.
Please send an example file where you see this problem.
Thanks.
Reply sent
to
Jorgen Schaefer <forcer <at> forcix.cx>
:
You have taken responsibility.
(Fri, 06 Jun 2014 09:53:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jorgen Schaefer <forcer <at> forcix.cx>
:
bug acknowledged by developer.
(Fri, 06 Jun 2014 09:53:03 GMT)
Full text and
rfc822 format available.
Message #13 received at 17714-done <at> debbugs.gnu.org (full text, mbox):
On Fri, 06 Jun 2014 12:22:15 +0300
Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Jorgen Schaefer <forcer <at> forcix.cx>
> > Date: Fri, 06 Jun 2014 10:24:53 +0200
> >
> > Since a few days ago, current trunk stopped detecting file coding
> > systems correctly for me. For a file that is opened as utf-8 with
> > stable Emacs, it now says (using emacs -q, fundamental-mode):
> >
> > -----
> > buffer-file-coding-system is a variable defined in `C source code'.
> > Its value is no-conversion
> > Local in buffer Todo; global value is utf-8-unix
> > -----
> >
> > M-x revert-buffer-with-coding-system RET utf-8 RET works fine.
>
> Please send an example file where you see this problem.
Hm. I *thought* I had seen the problem with more than one file, but it
turns out it was only one. The problem was that the file contained ^@
(zero bytes) from a yank from some process output. Which of course is
not valid utf-8.
Now I wonder why the file saved without error. There was some weird
vc error as well. Can't reproduce this now, though. So meh.
Sorry for the noise, nothing to see here. :-)
Jorgen
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17714
; Package
emacs
.
(Fri, 06 Jun 2014 11:45:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 17714 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 6 Jun 2014 11:51:57 +0200
> From: Jorgen Schaefer <forcer <at> forcix.cx>
> Cc: 17714-done <at> debbugs.gnu.org
>
> On Fri, 06 Jun 2014 12:22:15 +0300
> Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> The problem was that the file contained ^@ (zero bytes) from a yank
> from some process output.
When Emacs sees a null byte in a file, it automatically falls back to
no-conversion. You can inhibit that by setting
inhibit-null-byte-detection to non-nil (not that I advise that).
> Sorry for the noise, nothing to see here. :-)
No sweat.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 05 Jul 2014 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 45 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.