bug#12989: 24.3.50; buffer-file-type is not buffer-local

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Kazuhiro Ito]

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

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Eli Zaretskii]

> Date: Sun, 25 Nov 2012 12:58:01 +0900
> From: Kazuhiro Ito <kzhr@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.

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Stefan Monnier]

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

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Kazuhiro Ito <kzhr@d1.dion.ne.jp>, 12989@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.

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Richard Stallman]

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

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Juanma Barranquero]

On Mon, Nov 26, 2012 at 12:47 AM, Richard Stallman <rms@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

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Stefan Monnier]

> 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

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Kazuhiro Ito]

> 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

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Eli Zaretskii]

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

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Eli Zaretskii]

> Date: Sun, 25 Nov 2012 18:50:05 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 12989@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.

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Stefan Monnier]

> 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

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Michael Albinus <michael.albinus@gmx.de>,  12989@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.

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Michael Albinus]

Eli Zaretskii <eliz@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.

bug#12989: 24.3.50; buffer-file-type is not buffer-local

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  12989@debbugs.gnu.org
> Date: Sat, 09 Feb 2013 17:08:05 +0100
> 
> Eli Zaretskii <eliz@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.