On Wed 30 Jan 2013 22:18, l...@gnu.org (Ludovic Courtès) writes:
> Can we discuss this one in the other thread, so my little brain and
> mailbox don’t get confused? :-)
>
>> From 5512fe4f93e4e583ab538ae02dd98e5825252dc9 Mon Sep 17 00:00:00 2001
>> From: Andy Wingo
>> Date: Wed, 30 Jan 2013 10:17
Hello!
Andy Wingo skribis:
> On Tue 29 Jan 2013 18:09, Mark H Weaver writes:
[...]
>> However, 'open-input-file' should not auto-detect the encoding by
>> default,
>
> The ball is in your court now :)
Can we discuss this one in the other thread, so my little brain and
mailbox don’t get confu
Hi,
On Tue 29 Jan 2013 18:09, Mark H Weaver writes:
> Having slept on this, I think I agree that 'open-input-file' should
> auto-consume BOMs.
Patch attached.
> However, 'open-input-file' should not auto-detect the encoding by
> default,
The ball is in your court now :)
> and should only con
Mark H Weaver skribis:
> I wrote:
>> Having slept on this, I think I agree that 'open-input-file' should
>> auto-consume BOMs.
Good.
> So what should (open-file FILENAME "r+") do?
What about doing the same as for just “r”? I can’t think of any
reasonable scenario where this could be a problem
Andy Wingo writes:
> On Tue 29 Jan 2013 20:22, Neil Jerram writes:
>
>> (define (read-csv file-name)
>> (let ((s (utf16->string (get-bytevector-all (open-input-file file-name))
>>'little)))
>>
>> ;; Discard possible byte order mark.
>> (if (and (>= (string-lengt
On Tue 29 Jan 2013 20:22, Neil Jerram writes:
> (define (read-csv file-name)
> (let ((s (utf16->string (get-bytevector-all (open-input-file file-name))
> 'little)))
>
> ;; Discard possible byte order mark.
> (if (and (>= (string-length s) 1)
>(char=?
Mark H Weaver skribis:
>>> However, there’s no way to open a file in binary mode when using
>>> ‘open-input-file’, ‘call-with-input-file’, etc.
>>
>> We can add keyword or optional arguments of course. (Not suggesting
>> that we do so at this time though.)
>
> This has been on my TODO list for a
Andy Wingo writes:
> What do people think about this attached patch?
>
> Andy
>
>
>>From 831c3418941f2d643f91e3076ef9458f700a2c59 Mon Sep 17 00:00:00 2001
> From: Andy Wingo
> Date: Mon, 28 Jan 2013 22:41:34 +0100
> Subject: [PATCH] detect and consume byte-order marks for textual ports
In case
I wrote:
> Having slept on this, I think I agree that 'open-input-file' should
> auto-consume BOMs.
On the other hand, there's a nasty complication. Of course
(open-input-file FILENAME) is just (open-file FILENAME "r"), so the
auto-consuming logic should be in 'open-file'.
So what should (open-f
Hi,
l...@gnu.org (Ludovic Courtès) writes:
>> For textual files, it doesn’t seem unreasonable for ‘open-input-file’ to
>> consume the BOM, IMO. It’s not much different from the ‘eol-style’
>> transcoders.
Andy Wingo writes:
> I could go either way. I would prefer for open-input-file to consume
Hi,
[Ludo and Mark and I scribas]:
>>> * 'open-input-file' could perhaps auto-consume a BOM at the beginning of
>>> the stream, but *only* if the BOM is already in the encoding specified
>>> by the user (possibly via an explicit call to 'file-encoding').
>>
>> The problem is that we have no wa
Andy Wingo skribis:
[...]
>> Regarding byte-order marks, my preference is that users should explictly
>> consume BOMs if that's what they want (ideally using some convenience
>> procedure provided by Guile). Sometimes consuming the BOM is the wrong
>> thing. For example, if the user is copying
On Mon 28 Jan 2013 23:20, Mike Gran writes:
> So if there is a "coding:" line in the doc, I think it
> should nullify giving precedence to a UTF-16 BOM.
OK.
Cheers,
Andy
--
http://wingolog.org/
Hi Mark,
Let me work the other way around, starting at the problem and not a
potential solution.
There is a file:
https://cvs.khronos.org/svn/repos/ogl/trunk/ecosystem/public/sdk/docs/man3/glBlendEquationSeparate.xml
It is valid XML. It also has a UTF-8 BOM. It fails to parse in SSAX.
The
Hi Andy,
Andy Wingo writes:
> What do people think about this attached patch?
I'm strongly opposed to making 'open-input-file' any more clever than it
already is. Furthermore, I strongly believe that it should be much less
clever than it is now. Our basic textual I/O should be robust by
defaul
> What do people think about this attached patch?
>
> Andy
If you find the word
"coding" by scanning 8-bit char by 8-bit char, it can't
be UTF-16, since that would be more like
"c o d i n g :" with nulls interspersed.
While rather unlikely, it is a theoretical possibility
that a doc in encoding
16 matches
Mail list logo
