* bug#12989: 24.3.50; buffer-file-type is not buffer-local
@ 2012-11-25 3:58 Kazuhiro Ito
2012-11-25 16:50 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Kazuhiro Ito @ 2012-11-25 3:58 UTC (permalink / raw)
To: 12989
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
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2012-11-25 3:58 bug#12989: 24.3.50; buffer-file-type is not buffer-local Kazuhiro Ito
@ 2012-11-25 16:50 ` Eli Zaretskii
2012-11-25 21:16 ` Stefan Monnier
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Eli Zaretskii @ 2012-11-25 16:50 UTC (permalink / raw)
To: Kazuhiro Ito; +Cc: 12989
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2012-11-25 16:50 ` Eli Zaretskii
@ 2012-11-25 21:16 ` Stefan Monnier
2012-11-25 21:26 ` Eli Zaretskii
2012-11-25 23:47 ` Richard Stallman
2012-11-26 14:35 ` Kazuhiro Ito
2013-02-09 13:01 ` Eli Zaretskii
2 siblings, 2 replies; 14+ messages in thread
From: Stefan Monnier @ 2012-11-25 21:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Kazuhiro Ito, 12989
>> > 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
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2012-11-25 21:16 ` Stefan Monnier
@ 2012-11-25 21:26 ` Eli Zaretskii
2012-11-25 23:47 ` Richard Stallman
1 sibling, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2012-11-25 21:26 UTC (permalink / raw)
To: Stefan Monnier; +Cc: kzhr, 12989
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2012-11-25 21:16 ` Stefan Monnier
2012-11-25 21:26 ` Eli Zaretskii
@ 2012-11-25 23:47 ` Richard Stallman
2012-11-26 0:47 ` Juanma Barranquero
2012-11-26 1:26 ` Stefan Monnier
1 sibling, 2 replies; 14+ messages in thread
From: Richard Stallman @ 2012-11-25 23:47 UTC (permalink / raw)
To: Stefan Monnier; +Cc: kzhr, 12989
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2012-11-25 23:47 ` Richard Stallman
@ 2012-11-26 0:47 ` Juanma Barranquero
2012-11-26 1:26 ` Stefan Monnier
1 sibling, 0 replies; 14+ messages in thread
From: Juanma Barranquero @ 2012-11-26 0:47 UTC (permalink / raw)
To: rms; +Cc: kzhr, 12989
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
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2012-11-25 23:47 ` Richard Stallman
2012-11-26 0:47 ` Juanma Barranquero
@ 2012-11-26 1:26 ` Stefan Monnier
1 sibling, 0 replies; 14+ messages in thread
From: Stefan Monnier @ 2012-11-26 1:26 UTC (permalink / raw)
To: rms; +Cc: kzhr, 12989
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2012-11-25 16:50 ` Eli Zaretskii
2012-11-25 21:16 ` Stefan Monnier
@ 2012-11-26 14:35 ` Kazuhiro Ito
2012-11-26 17:24 ` Eli Zaretskii
2013-02-09 13:01 ` Eli Zaretskii
2 siblings, 1 reply; 14+ messages in thread
From: Kazuhiro Ito @ 2012-11-26 14:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 12989
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2012-11-26 14:35 ` Kazuhiro Ito
@ 2012-11-26 17:24 ` Eli Zaretskii
0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2012-11-26 17:24 UTC (permalink / raw)
To: Kazuhiro Ito; +Cc: 12989
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2012-11-25 16:50 ` Eli Zaretskii
2012-11-25 21:16 ` Stefan Monnier
2012-11-26 14:35 ` Kazuhiro Ito
@ 2013-02-09 13:01 ` Eli Zaretskii
2013-02-09 14:29 ` Stefan Monnier
2013-02-09 16:08 ` Michael Albinus
2 siblings, 2 replies; 14+ messages in thread
From: Eli Zaretskii @ 2013-02-09 13:01 UTC (permalink / raw)
To: Michael Albinus, Stefan Monnier; +Cc: 12989
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2013-02-09 13:01 ` Eli Zaretskii
@ 2013-02-09 14:29 ` Stefan Monnier
2013-02-09 16:21 ` Eli Zaretskii
2013-02-09 16:08 ` Michael Albinus
1 sibling, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2013-02-09 14:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Michael Albinus, 12989
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2013-02-09 14:29 ` Stefan Monnier
@ 2013-02-09 16:21 ` Eli Zaretskii
0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2013-02-09 16:21 UTC (permalink / raw)
To: Stefan Monnier; +Cc: michael.albinus, 12989
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2013-02-09 13:01 ` Eli Zaretskii
2013-02-09 14:29 ` Stefan Monnier
@ 2013-02-09 16:08 ` Michael Albinus
2013-02-09 16:17 ` Eli Zaretskii
1 sibling, 1 reply; 14+ messages in thread
From: Michael Albinus @ 2013-02-09 16:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 12989
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#12989: 24.3.50; buffer-file-type is not buffer-local
2013-02-09 16:08 ` Michael Albinus
@ 2013-02-09 16:17 ` Eli Zaretskii
0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2013-02-09 16:17 UTC (permalink / raw)
To: Michael Albinus; +Cc: 12989
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-02-09 16:21 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-25 3:58 bug#12989: 24.3.50; buffer-file-type is not buffer-local Kazuhiro Ito
2012-11-25 16:50 ` Eli Zaretskii
2012-11-25 21:16 ` Stefan Monnier
2012-11-25 21:26 ` Eli Zaretskii
2012-11-25 23:47 ` Richard Stallman
2012-11-26 0:47 ` Juanma Barranquero
2012-11-26 1:26 ` Stefan Monnier
2012-11-26 14:35 ` Kazuhiro Ito
2012-11-26 17:24 ` Eli Zaretskii
2013-02-09 13:01 ` Eli Zaretskii
2013-02-09 14:29 ` Stefan Monnier
2013-02-09 16:21 ` Eli Zaretskii
2013-02-09 16:08 ` Michael Albinus
2013-02-09 16:17 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).