GNU bug report logs - #12989
24.3.50; buffer-file-type is not buffer-local

Previous Next

Full log

Message #26 received at 12989 <at> debbugs.gnu.org (full text, mbox):

From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12989 <at> debbugs.gnu.org
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Mon, 26 Nov 2012 23:35:20 +0900

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.