From: Michael Selig <michael.selig@...>
Date: 2008-10-26T17:20:17+09:00
Subject: [ruby-core:19518] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch))

On Sun, 26 Oct 2008 17:26:32 +1100, Nobuyoshi Nakada <nobu@ruby-lang.org>  
wrote:


> I'd prefer to default the internal encoding to the source
> encoding of the main script.

But then how do you tell Ruby NOT to set "default_internal"?
It also means that comments must be in the default_internal encoding (see  
your comment below).

>> 3)
>> Perhaps this check could be based on the library's source encoding? If
>> this were done, most libraries would have to use a source encoding of
>> US-ASCII (or just have no encoding magic comment) *not* UTF-8, so that
>> non-Unicode default_internal's will work. Perhaps Ruby could be smarter,
>> and only flag an error if there actually is an incomaptible string  
>> literal
>> in the library?
>
> What about comments?  I suspect it might not a good idea.

That is why I suggested that, if possible, it should check for *actual*  
string literals in the library, rather than the source encoding. This may  
be hard to implement though.

>
>> 4)
>> Also it means that:
>> 	ruby test.rb
>> may perform differently than:
>> 	ruby -e "`cat test.rb`"
>
> magic comments are effective with -e too.
>
> $ ruby19 -e 'p __ENCODING__'
> #<Encoding:EUC-JP>
>
> $ ruby19 -e '#-*- encoding:utf-8 -*-' -e 'p __ENCODING__'
> #<Encoding:UTF-8>
>
> Therefore no differences if the file has the magic comment.

That's true, but my point was "why should a simple non-m17n non-ascii ruby  
program have to contain the magic comment"?

Thanks,
Mike