[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: finalize or withdraw?
Michael Sperber wrote:
Per Bothner <per@xxxxxxxxxxx> writes:
Sure. I'm only pointing out that a notion of "default encoding" may
If I then as a beginning Scheme programmer write a program
to read this file, I should not have to use an magic options
or commands to do so - it should just work, even if my
default encoding is different from with UTF-8.
not exist on your platform, or that it may not be reasonable, even for
"default" cases, to enforce one upon the application.
"Default encoding" may vary from user to user (at least on Unix-like
platforms). And if each file includes an "encoding" attribute,
then there is less need for the concept of a default encoding.
But the concept is still needed, to specify the encoding to be
used when creating a new text file, and to define an implicit
encoding for existing text files without an encoding attribute.
the "default encoding" may be different for files (or for files in
different file systems) and the console.
It could be. I don't think that's a problem.
But perhaps you could comment on do you expect this to work? Assume
I'm Japanese and using some version of JIS. (Or a German using
Latin-1, for that matter.) How should my Scheme implementation handle
Make (standard-input-port) and frieds return suitable transcoded
ports. I think you probably want this to work for files as well, but
I don't think it makes sense there, as explained above.
I disagree. open-output-file should create a file using the
default encoding. And when open-input-file read a file, if the
platform doesn't supply an encoding attribute, it should use
the default one.
Let me emphasize again: It is essential that open-output-file
create a file using the same encoding that the rest of my
environment expects. I should be able to open the file
using my default editor. If I cat/type/view the file, my
terminal should display the correct glyphs, and not be garbled.