[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12989: 24.3.50; buffer-file-type is not buffer-local
From: |
Kazuhiro Ito |
Subject: |
bug#12989: 24.3.50; buffer-file-type is not buffer-local |
Date: |
Mon, 26 Nov 2012 23:35:20 +0900 |
User-agent: |
Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/24.3.50 (i386-mingw-nt6.1.7601) MULE/6.0 (HANACHIRUSATO) |
> buffer-file-type was removed from the
> C code, with the goal of removing it entirely, but there are still
> traces of it in Lisp. I'm surprised you only noticed this now.
A symptom of the problem is that Emacs becomes not to decode contents
of files before one knows while I use Emacs (with some elisp
packages). The problem is long standing and annoying me and I had not
been able to find out the trigger of the problem.
But I think I found it out just now. Modifying and saving gzipped
text on Windows causes the problem. Because jka-compr-write-region
(in lisp/jka-compr.el) sets buffer-file-type to t.
> If you want to force Emacs to treat certain files as binary, bind
> coding-system-for-read to 'binary or modify file-coding-system-alist
> accordingly.
In my report, coding-system-for-read is bound to 'no-conversion. Do
you mean we should use 'binary instead of 'no-conversion?
In lisp/dos-w32.el
> (defun find-file-not-found-set-buffer-file-coding-system ()
(snip)
> (setq buffer-file-type (eq buffer-file-coding-system 'no-conversion)))))
The above line modifies buffer-file-type's value and makes the
difference between 'binary and 'no-conversion. But I would doubt that
the difference is intentionally made.
--
Kazuhiro Ito