--- Begin Message ---
|
Subject: |
24.3.50; buffer-file-coding-system not set correctly |
|
Date: |
Sat, 16 Mar 2013 14:49:17 +0000 |
On Windows, visit a plain ASCII text file with LF line endings. The
value of `buffer-file-coding-system' is `iso-latin-1-dos' (should be
`iso-latin-1-unix'). Modify and save the file. The file now has CRLF
line endings.
This was introduced recently in the trunk.
In GNU Emacs 24.3.50.1 (i386-mingw-nt6.2.9200)
of 2013-03-16 on MACHINE
Bzr revision: 112057 address@hidden
Windowing system distributor `Microsoft Corp.', version 6.2.9200
Configured using:
`configure --with-gcc (4.7) --cflags -I c:/gnuwin32/include --ldflags
-L c:/gnuwin32/lib'
Important settings:
value of $LANG: ENG
locale-coding-system: cp1252
default enable-multibyte-characters: t
Major mode: Text
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
C-x C-f n e w . t x t <return> a <return> b <return>
c <return> C-x <return> c u n i x <return> C-x C-s
M-: ( n t h SPC 7 SPC ( f i l e - a t t r i b u t e s
SPC " n e w . t x t " ) ) <return> C-x C-v <return>
SPC <backspace> C-x C-s M-: <up> <return> M-x r e p o
r t - e m a c s - b u f <backspace> g <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
(New file)
Saving file c:/Users/Buster/new.txt...
Wrote c:/Users/Buster/new.txt
6 (#o6, #x6)
Saving file c:/Users/Buster/new.txt...
Wrote c:/Users/Buster/new.txt
9 (#o11, #x9)
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win
w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32notify w32
multi-tty emacs)
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#13977: 24.3.50; buffer-file-coding-system not set correctly |
|
Date: |
Fri, 05 Apr 2013 23:50:04 +0400 |
|
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 |
Cc-ing the bug for the public record and to mark it done.
Version: 24.4
On 05.04.2013 23:35, Richard Copley wrote:
Damn, 7 minutes 11 seconds for the bootstrap alone, plus a few minutes
to test and write this email.
Thanks for checking, I'm in no hurry. :)
(Forgot about having to recreate ja-dic. I
wonder whether some of that work could be split into different targets
for Make to parallelize?)
This isn't performed too often, I think I've only seen it recreated
once, after this bug has been introduced.
Anyway, yes it seems fixed for me. Many thanks!
On 5 April 2013 20:22, Richard Copley <address@hidden
<mailto:address@hidden>> wrote:
I'll bootstrap, give me six and a half minutes.
On 5 April 2013 20:19, Dmitry Gutov <address@hidden
<mailto:address@hidden>> wrote:
Richard Copley <address@hidden <mailto:address@hidden>>
writes:
> On Windows, visit a plain ASCII text file with LF line
endings. The
> value of `buffer-file-coding-system' is `iso-latin-1-dos'
(should be
> `iso-latin-1-unix'). Modify and save the file. The file now
has CRLF
> line endings.
> This was introduced recently in the trunk.
I think this has been fixed, likely in the revision 112229.
Richard, could you test?
--- End Message ---