unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#7001: should `byte-compile-from-buffer' evaluate `binary-overwrite-mode' explicitly?
@ 2010-09-08 21:01 MON KEY
  2010-09-09 17:02 ` Stefan Monnier
  0 siblings, 1 reply; 6+ messages in thread
From: MON KEY @ 2010-09-08 21:01 UTC (permalink / raw)
  To: 7001

emacs-lisp/bytecomp.el

`byte-compile-from-buffer'

Has this form:

 (setq overwrite-mode 'overwrite-mode-binary)

Should this evalatate `binary-overwrite-mode'  from simple.el instead?

Or, is there a boostrapping issue which prevents this?

--
/s_P\





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#7001: should `byte-compile-from-buffer' evaluate `binary-overwrite-mode' explicitly?
  2010-09-08 21:01 bug#7001: should `byte-compile-from-buffer' evaluate `binary-overwrite-mode' explicitly? MON KEY
@ 2010-09-09 17:02 ` Stefan Monnier
  2010-10-02 23:11   ` Chong Yidong
  0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2010-09-09 17:02 UTC (permalink / raw)
  To: MON KEY; +Cc: 7001

> Has this form:
>  (setq overwrite-mode 'overwrite-mode-binary)
> Should this evalatate `binary-overwrite-mode'  from simple.el instead?

Probably not, since that would run binary-overwrite-mode-hook.
Most likely this line can be removed from bytecomp.el.


        Stefan





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#7001: should `byte-compile-from-buffer' evaluate `binary-overwrite-mode' explicitly?
  2010-09-09 17:02 ` Stefan Monnier
@ 2010-10-02 23:11   ` Chong Yidong
  2010-10-03  4:04     ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Chong Yidong @ 2010-10-02 23:11 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 7001, MON KEY

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Has this form:
>>  (setq overwrite-mode 'overwrite-mode-binary)
>> Should this evalatate `binary-overwrite-mode'  from simple.el instead?
>
> Probably not, since that would run binary-overwrite-mode-hook.

I've added a comment about this.

> Most likely this line can be removed from bytecomp.el.

The comments in bytecomp.el say this is needed for DOS.  No harm leaving
it in, I suppose.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#7001: should `byte-compile-from-buffer' evaluate `binary-overwrite-mode' explicitly?
  2010-10-02 23:11   ` Chong Yidong
@ 2010-10-03  4:04     ` Eli Zaretskii
  2010-10-03  4:32       ` Chong Yidong
  0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2010-10-03  4:04 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 7001, monkey

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 02 Oct 2010 19:11:13 -0400
> Cc: 7001@debbugs.gnu.org, MON KEY <monkey@sandpframing.com>
> 
> > Most likely this line can be removed from bytecomp.el.
> 
> The comments in bytecomp.el say this is needed for DOS.

That comment is obsolete.  All file I/O works in binary mode on DOS
and Windows since at least 15 years ago.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#7001: should `byte-compile-from-buffer' evaluate `binary-overwrite-mode' explicitly?
  2010-10-03  4:04     ` Eli Zaretskii
@ 2010-10-03  4:32       ` Chong Yidong
  2010-10-03  5:43         ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Chong Yidong @ 2010-10-03  4:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 7001, monkey

Eli Zaretskii <eliz@gnu.org> writes:

>>
>> > Most likely this line can be removed from bytecomp.el.
>>
>> The comments in bytecomp.el say this is needed for DOS.
>
> That comment is obsolete.  All file I/O works in binary mode on DOS
> and Windows since at least 15 years ago.

Wow, that's some history ;-)  I've removed the line; thanks.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#7001: should `byte-compile-from-buffer' evaluate `binary-overwrite-mode' explicitly?
  2010-10-03  4:32       ` Chong Yidong
@ 2010-10-03  5:43         ` Eli Zaretskii
  0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2010-10-03  5:43 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 7001, monkey

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: monnier@iro.umontreal.ca, 7001@debbugs.gnu.org, monkey@sandpframing.com
> Date: Sun, 03 Oct 2010 00:32:15 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >>
> >> > Most likely this line can be removed from bytecomp.el.
> >>
> >> The comments in bytecomp.el say this is needed for DOS.
> >
> > That comment is obsolete.  All file I/O works in binary mode on DOS
> > and Windows since at least 15 years ago.
> 
> Wow, that's some history ;-)  I've removed the line; thanks.

Just for the record: I meant to say that _Emacs_ file I/O on
DOS/Windows works in binary mode, not that DOS/Windows in general do
that.  The following part in emacs.c does the trick:

  #if defined (MSDOS) || defined (WINDOWSNT)
    /* We do all file input/output as binary files.  When we need to translate
       newlines, we do that manually.  */
    _fmode = O_BINARY;
  #endif /* MSDOS || WINDOWSNT */

  #ifdef MSDOS
    if (!isatty (fileno (stdin)))
      setmode (fileno (stdin), O_BINARY);
    if (!isatty (fileno (stdout)))
      {
	fflush (stdout);
	setmode (fileno (stdout), O_BINARY);
      }
  #endif /* MSDOS */





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-10-03  5:43 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-08 21:01 bug#7001: should `byte-compile-from-buffer' evaluate `binary-overwrite-mode' explicitly? MON KEY
2010-09-09 17:02 ` Stefan Monnier
2010-10-02 23:11   ` Chong Yidong
2010-10-03  4:04     ` Eli Zaretskii
2010-10-03  4:32       ` Chong Yidong
2010-10-03  5:43         ` 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).