From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: Scanning for coding declarations in all files (not just source)
Date: Tue, 15 Jan 2013 10:32:17 +0100 [thread overview]
Message-ID: <8738y2x04e.fsf@gnu.org> (raw)
In-Reply-To: 87zk0dq6sb.fsf@tines.lan
Hi,
Mark H Weaver <mhw@netris.org> skribis:
> I just discovered that Guile is scanning for coding declarations in
> *all* files opened with 'open-file', not just source files.
Yeah, I don’t really like it either.
> For source files, we are scanning for coding declarations twice: once
> when when the file is opened, and a second time when 'compile-file' or
> 'primitive-load' explicitly scans for it.
Yes, I think I’m used to writing things like:
(call-with-input-file file
(lambda (p)
(set-port-encoding! p (file-encoding p))
...))
when I really want that behavior.
One thing I noticed lately is that ‘call-with-input-file’ & co. never
use the “b” flag, so if what you want is really an binary input file,
you have to resort to hacks like:
(define (call-with-latin1-input-file file proc)
"Open FILE as an latin1 or binary file, and pass the resulting port to
PROC. FILE is closed when PROC's dynamic extent is left. Return the
return values of applying PROC to the port."
(let ((port (with-fluids ((%default-port-encoding #f))
;; Use "b" so that `open-file' ignores `coding:' cookies.
(open-file file "rb"))))
(dynamic-wind
(lambda ()
#t)
(lambda ()
(proc port))
(lambda ()
(close-input-port port)))))
Also, guessing for all files may cause problems with non-seekable files,
or pseudo files.
> I don't like this. I don't want 'open-file' to second-guess the
> encoding I have asked for in my program, based on data in the file.
> Also, the manual is misleading. Section 6.17.8 gives the impression
> that the scanning is only done for source files.
That may reflect what I’ve been thinking for some time. ;-)
Mike Gran <spk121@yahoo.com> skribis:
> Opening a file that contains a coding declaration using an encoding other
> than binary or the coding declared in the file seems like it would be
> something of a corner case. So, IMHO it makes sense that opening a file
> using its self-declared encoding should be the simple case, and that
> opening a text file in a different (non-binary) text encoding should
> be the more complicated case, in a API sense.
That’s also true. In Emacs, we want files to be opened with the right
encoding, whatever happens; so in some cases we could have the same
expectations here.
As usual, backward-compatibility gives us an incentive not to change
anything in 2.0. But perhaps we should change that in 2.2.
Thoughts?
Ludo’.
next prev parent reply other threads:[~2013-01-15 9:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-13 18:25 Scanning for coding declarations in all files (not just source) Mark H Weaver
2013-01-13 19:51 ` Mike Gran
2013-01-15 9:32 ` Ludovic Courtès [this message]
2013-01-22 11:38 ` Andy Wingo
2013-01-31 5:06 ` [PATCH] Do not scan for coding declarations in open-file Mark H Weaver
2013-01-31 10:00 ` Andy Wingo
2013-01-31 18:58 ` Mark H Weaver
2013-01-31 20:04 ` Andy Wingo
2013-01-31 22:00 ` Ludovic Courtès
2013-01-31 22:19 ` Noah Lavine
2013-01-31 21:51 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8738y2x04e.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).