Andy Wingo <wi...@pobox.com> skribis:
> On Thu 31 Jan 2013 06:06, Mark H Weaver <m...@netris.org> writes:
>
>> From: Mark H Weaver <m...@netris.org>
>> Date: Wed, 30 Jan 2013 14:45:28 -0500
>> Subject: [PATCH] Do not scan for coding declarations in open-file.
>
> The patch looks good to me but I am concerned about the behavior
> change, and that it is inconvenient to get the previous behavior.
I’m concerned too.
However, I’ve been explicitly using ‘file-encoding’ “forever” when I
really wanted to handle coding cookies. Actually the doc even
explicitly recommends this (info "(guile) Character Encoding of Source
Files"):
If a port is used to read code of unknown character encoding, it can
accomplish this in three steps. First, the character encoding of the
port should be set to ISO-8859-1 using `set-port-encoding!'. Then, the
procedure `file-encoding', described below, is used to scan for a
coding declaration when reading from the port. As a side effect, it
rewinds the port after its scan is complete. After that, the port's
character encoding should be set to the encoding returned by
`file-encoding', if any, again by using `set-port-encoding!'. Then the
code can be read as normal.
Considering this, it is tempting to think that removing that
scm_i_scan_for_encoding call would be a bug fix.
WDYT?
> My instinct is that we should not merge this patch without including a
> way to enable the coding sniff; which seems to mean adding keywords or
> somehow extending the arguments of:
>
> open-file
> with-input-from-file
> with-output-to-file
> call-with-output-file
> call-with-input-file
> open-input-file
>
> Dunno; that is a larger task. I'd be interested in Ludovic's thoughts
> as well.
There are several issues IMO. First, some are subrs, so handling
keyword arguments is going to be painful. Second, keyword arguments are
inelegant IMO compared to:
(set-port-encoding! port (file-encoding port))
Thanks,
Ludo’.
