[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Do not scan for coding declarations in open-file

From: Ludovic Courtès
Subject: Re: [PATCH] Do not scan for coding declarations in open-file
Date: Thu, 31 Jan 2013 23:00:54 +0100
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)

Andy Wingo <address@hidden> skribis:

> On Thu 31 Jan 2013 06:06, Mark H Weaver <address@hidden> writes:
>> From: Mark H Weaver <address@hidden>
>> 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

     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.


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]