From: Nobuyoshi Nakada <nobu@...>
Date: 2008-10-27T15:27:57+09:00
Subject: [ruby-core:19533] Re: String literal encoding (Was: Default source encoding (Was: [Bug #680] csv.rb: CSV.parse is toolate when encoding is mismatch))

Hi,

At Mon, 27 Oct 2008 14:48:41 +0900,
Michael Selig wrote in [ruby-core:19532]:
> 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?

No.  Magic comments without -*- markers are for VIM, like
# vim: set encoding=UTF-8
and, both of VIM and Emacs wouldn't work with your examples.

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

Even in 1.8 or prior, -Ks has been mandatory for Shift_JIS
sources, so they have had -K in the shebang lines already.

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

Yes if they match.

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

-U option would be better.

-- 
Nobu Nakada