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

On Mon, 27 Oct 2008 16:07:54 +1100, Nobuyoshi Nakada <nobu@ruby-lang.org>  
wrote:

> But it can't keep the source encoding unset, and
> "internal_encoding" has no effect for Emacs.

OK, I don't use Emacs, and no one told me that before, thanks! I assumed  
it would work, but I admit I didn't test it.
Then is there another form of magic comment that can be used - eg:  
"internal encoding: XXXX" or "encoding: XXXX internal" that does work with  
Emacs?

I am not sure why you would want to keep the source encoding unset when  
setting default_internal at the top of a script. Perhaps you could explain.

>> Isn't backward compatibility with 1.8 scripts more important?
>> You are now forcing anyone with 1.8 scripts containing non-ascii string
>> literals to put in a magic comment, otherwise you get "inavlid multibyte
>> char (US-ASCII)" error in 1.9.
>
> In other words, what you want is -K option?

What I am saying is that we need to consider backward compatibility of  
Ruby scripts. James Grey brought up an example with his "Textmate scripts"  
which contain UTF-8 multibyte string literals, which used to work with  
1.8, but do not in 1.9, because they need either a "magic comment" or, as  
you say "-KU". Either way, 1.9 is not truly backward compatible when it  
comes to simple, non-m17n, non-ascii scripts, because you have to either  
modify the script or add a flag to the ruby options. There must be lots of  
Japanese ruby scripts which will have a similar issue.

Defaulting source encoding to locale encoding (like -e does) should fix  
this (as long as the end-user's locale is correct), right?

I guess if necessary James can put "-KU" in the RUBYOPT environment  
variable to save having to add multiple magic comments, but I feel this  
shouldn't be necessary.

Cheers
Mike