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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12989 in the body.
You can then email your comments to 12989 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; buffer-file-type is not buffer-local
Date: Sun, 25 Nov 2012 12:58:01 +0900

When I evaluate below code, Emacs-23 and trunk on Windows return the
different results.

(list
 (setq buffer-file-type nil)
 (progn
   (let ((coding-system-for-read 'no-conversion))
     ;; Specify non-existing file.
     (kill-buffer (find-file-noselect "c:/zzzzzzz")))
   buffer-file-type))

-> (nil nil) (Emacs 23)
-> (nil t) (trunk)

And, if buffer-file-type is set to t, many file coding system
detections fail.  Docstring says that buffer-file-type autmatically
becomes buffer-local, but that is not true on trunk.

> buffer-file-type is a variable defined in `subr.el'.
> Its value is nil
> 
> Documentation:
> Non-nil if the visited file is a binary file.
> This variable is meaningful on MS-DOG and Windows NT.
> On those systems, it is automatically local in every buffer.
> On other systems, this variable is normally always nil.


Additionally, there is typo in docsstring of buffer-file-type.

> This variable is meaningful on MS-DOG and Windows NT.
                                 ~~~~~~

-- 
Kazuhiro Ito

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
Cc: 12989 <at> debbugs.gnu.org
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Sun, 25 Nov 2012 18:50:05 +0200

> Date: Sun, 25 Nov 2012 12:58:01 +0900
> From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
> 
> When I evaluate below code, Emacs-23 and trunk on Windows return the
> different results.

The difference is intentional.  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.

> And, if buffer-file-type is set to t, many file coding system
> detections fail.  Docstring says that buffer-file-type autmatically
> becomes buffer-local, but that is not true on trunk.

Just don't use that variable.  You don't need it.  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.

I will work on removing the variable entirely from the sources, though
I guess it's too late for 24.3.  So I will do it on the trunk.

> Additionally, there is typo in docsstring of buffer-file-type.
> 
> > This variable is meaningful on MS-DOG and Windows NT.
>                                  ~~~~~~

It's not a typo.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>, 12989 <at> debbugs.gnu.org
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Sun, 25 Nov 2012 16:16:13 -0500

>> > This variable is meaningful on MS-DOG and Windows NT.
>>                                  ~~~~~~
> It's not a typo.

BTW, doesn't Emacs now run under Free Software compatible with
"MS-DOS", right?  If so, could we refer to this instead of
MS-DOS/MS-DOG?


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: kzhr <at> d1.dion.ne.jp, 12989 <at> debbugs.gnu.org
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Sun, 25 Nov 2012 23:26:54 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>, 12989 <at> debbugs.gnu.org
> Date: Sun, 25 Nov 2012 16:16:13 -0500
> 
> >> > This variable is meaningful on MS-DOG and Windows NT.
> >>                                  ~~~~~~
> > It's not a typo.
> 
> BTW, doesn't Emacs now run under Free Software compatible with
> "MS-DOS", right?

Probably.  I never tried that, so I cannot tell.

> If so, could we refer to this instead of MS-DOS/MS-DOG?

Its name is not MS-DOS.  It's FreeDOS.

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

From: Richard Stallman <rms <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: eliz <at> gnu.org, kzhr <at> d1.dion.ne.jp, 12989 <at> debbugs.gnu.org
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Sun, 25 Nov 2012 18:47:30 -0500

Microsoft called it "MS-DOS".  We call it "MS-DOG" as an insult.

Is it the case that MS-DOS is now dead and people only use FreeDOS?
If so, maybe we should talk about FreeDOS and maybe stop mentioning
MS-DOS at all.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: rms <at> gnu.org
Cc: kzhr <at> d1.dion.ne.jp, 12989 <at> debbugs.gnu.org,
	Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Mon, 26 Nov 2012 01:47:17 +0100

On Mon, Nov 26, 2012 at 12:47 AM, Richard Stallman <rms <at> gnu.org> wrote:

> Microsoft called it "MS-DOS".  We call it "MS-DOG" as an insult.

<sigh>

> Is it the case that MS-DOS is now dead and people only use FreeDOS?

Depends on your definition of "dead". The last Windows release to
support booting MS-DOS was Windows Me (and the user had to jump
through some hoops). So it's been 12 years since Microsoft last
released an MS-DOS into the world. Windows Me has been unsupported
since July, 2006.

    Juanma

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: rms <at> gnu.org
Cc: eliz <at> gnu.org, kzhr <at> d1.dion.ne.jp, 12989 <at> debbugs.gnu.org
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Sun, 25 Nov 2012 20:26:30 -0500

> Microsoft called it "MS-DOS".  We call it "MS-DOG" as an insult.
> Is it the case that MS-DOS is now dead and people only use FreeDOS?
> If so, maybe we should talk about FreeDOS and maybe stop mentioning
> MS-DOS at all.

Exactly.  Wouldn't it be better to advertize a GPL'd software than
a proprietary one?


        Stefan

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
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 19:24:48 +0200

> Date: Mon, 26 Nov 2012 23:35:20 +0900
> From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
> Cc: 12989 <at> debbugs.gnu.org
> 
> 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.

Yes, this is one of the places left that set this variable.  Another
one is in bytecomp.el, in Tramp, and a few more elsewhere.  I will
remove them all in the trunk, after careful consideration what to
replace them with.

To repeat what I wrote in emacs-devel, for the record: revision 110960
on the emacs-24 branch made buffer-file-type buffer-local again, and
find-file-not-found-set-buffer-file-coding-system no longer sets this
variable if buffer-file-coding-system is no-conversion.

> > 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?

No.  (These two are the same.)  I thought you were setting the
variable in your code or in your customizations, and suggested to use
the standard facilities instead.  But since the problem comes from
Emacs itself, that advice is no longer valid.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>,
	Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 12989 <at> debbugs.gnu.org
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Sat, 09 Feb 2013 15:01:44 +0200

> Date: Sun, 25 Nov 2012 18:50:05 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 12989 <at> debbugs.gnu.org
> 
> I will work on removing the variable entirely from the sources, though
> I guess it's too late for 24.3.  So I will do it on the trunk.

Now done (revision 111709 on the trunk).

There are still references to find-buffer-file-type (which no longer
exists as of the above revision) in tramp-sh.el.  The code there is
commented as being for XEmacs only, and I don't really understand what
is it trying to accomplish.  Michael, could you please take a look?
Ideally, we should delete all that stuff, unless it breaks XEmacs.

A question for Stefan: should I also remove these from subr.el:

  (make-obsolete-variable 'default-buffer-file-type 'buffer-file-type "23.2")
  (defvar-local buffer-file-type nil
    "Non-nil if the visited file is a binary file.
  This variable is meaningful on MS-DOG and MS-Windows.
  On those systems, it is automatically local in every buffer.
  On other systems, this variable is normally always nil.

  WARNING: This variable is obsolete and will disappear Real Soon Now.
  Don't use it!")

I thought I'd leave them in case some non-bundled code uses them.  But
maybe this is not needed.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12989 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Sat, 09 Feb 2013 09:29:18 -0500

> A question for Stefan: should I also remove these from subr.el:

Not sure.

> I thought I'd leave them in case some non-bundled code uses them.  But
> maybe this is not needed.

I'll let you judge.  If all users just let-bind or setq those vars,
there's no need to keep them around.  I'd suggest to remove them, and
if/when someone complains about resulting breakage, we may revisit
this choice.


        Stefan

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12989 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Sat, 09 Feb 2013 17:08:05 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> There are still references to find-buffer-file-type (which no longer
> exists as of the above revision) in tramp-sh.el.  The code there is
> commented as being for XEmacs only, and I don't really understand what
> is it trying to accomplish.  Michael, could you please take a look?
> Ideally, we should delete all that stuff, unless it breaks XEmacs.

`tramp-sh-handle-insert-file-contents-literally', which calls
`find-buffer-file-type', is used only for XEmaxs. Emacs does not call a
file name handler for `insert-file-contents-literally'.

So I would like to let it as it is; I don't know whether it would break
XEmacs when we remove that code. I run XEmacs extremely rarely.

Best regards, Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 12989 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Sat, 09 Feb 2013 18:17:39 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  12989 <at> debbugs.gnu.org
> Date: Sat, 09 Feb 2013 17:08:05 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > There are still references to find-buffer-file-type (which no longer
> > exists as of the above revision) in tramp-sh.el.  The code there is
> > commented as being for XEmacs only, and I don't really understand what
> > is it trying to accomplish.  Michael, could you please take a look?
> > Ideally, we should delete all that stuff, unless it breaks XEmacs.
> 
> `tramp-sh-handle-insert-file-contents-literally', which calls
> `find-buffer-file-type', is used only for XEmaxs. Emacs does not call a
> file name handler for `insert-file-contents-literally'.
> 
> So I would like to let it as it is; I don't know whether it would break
> XEmacs when we remove that code. I run XEmacs extremely rarely.

Thanks for looking.  Leaving the code as it is would be fine with me.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 12989 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#12989: 24.3.50; buffer-file-type is not buffer-local
Date: Sat, 09 Feb 2013 18:21:06 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Michael Albinus <michael.albinus <at> gmx.de>,  12989 <at> debbugs.gnu.org
> Date: Sat, 09 Feb 2013 09:29:18 -0500
> 
> > A question for Stefan: should I also remove these from subr.el:
> 
> Not sure.
> 
> > I thought I'd leave them in case some non-bundled code uses them.  But
> > maybe this is not needed.
> 
> I'll let you judge.  If all users just let-bind or setq those vars,
> there's no need to keep them around.  I'd suggest to remove them, and
> if/when someone complains about resulting breakage, we may revisit
> this choice.

I removed them, thanks for the feedback.

Previous Next

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