Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix some failing rubyspecs for String#encode #684
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.