Join GitHub today
Fix some failing rubyspecs for String#encode #684
added a commit
this pull request
Apr 30, 2013
This seems to have introduced a failure; test/externals/ruby1.9/ruby/test_m17n.rb fails in test_split when it gets to the Emacs-Mule encoding. I'm looking into that, but if you have a change to fix I'd appreciate it. I already merged your changes.
Also a small style note: we only allow the no-braces form of "if" if it's a one-liner; you have a few cases in your patches where you use that form along with else, which we just consider confusing and error-prone. If you can't do everything in one line, use braces please. Thanks :-)
Ok, I think I understand the failure. Because of the 7bit change, Emacs-MULE is now getting hit as an encoding. However, it's not an encoding we support transcoding for yet, and I think that triggers the issue.
I also have a change for your 7bit fix that uses an already-known bit in RubyString for coderange that indicates if it's all 7bit characters, rather than scanning the whole string every time.
It seems like there must be a bug in this encoding. The logic for split basically just walks the string's characters, shifting as many bytes as necessary for each character in turn. I think somewhere along the way it's shifting too far so we get the weird "c", "def" split in test_m17n#test_split.
When I print out "p" and "t" in the loop in RubyString#stringSplit19 I get the following for the last two encodings in test_m17n#test_split (CP949, which works, and Emacs-Mule, which doesn't):
Seems like something's borked in Emacs-Mule's rightAdjustCharHead.