2014-03-25

How to Change Atom's `navigator.language`

After tinkering a bit, I've finally figured out how to change the navigator.language! I ended up having to modify the libchromiumcontent.dylib bundled inside Atom.app...
$ cmp -bl {orig,ja-JP}/Atom.app/Contents/Frameworks/Atom\ Framework.framework/Versions/A/Libraries/libchromiumcontent.dylib
43700712 145 e 152 j
43700713 156 n 141 a
43700715 125 U 112 J
43700716 123 S 120 P
This is the value that is used for navigator.language. Once patched as above, navigator.language will return "ja-JP".

2014-03-21

Block Cursor for Atom

Atom's cursor doesn't change to cover the character behind it.  So, if you work with CJK files and want a block cursor (à la vim-mode), then you're left with a half-character-width cursor (the cursor width is set to one   by default).

I made a patch for Atom v0.75.0 to fix this issue.

  • CJK Character
    • Before:
    • After:
  • Tab
    • Before:
    • After:

Atom File Types

There wasn't a straight-forward way to associate an arbitrary file type (file extension) with a grammar in Atom.  So, I made a package to do just that.

https://atom.io/packages/file-types

2012-10-04

The Node.js REPL and Backslashes in Strings

I thought there was something weird going on with the node.js REPL's handling of backslashes in Strings. I was thinking, "Why are there twice as many backslashes!?" Then, it hit me: the output is correct! It is escaping the value of the string, just as if a programmer were to have typed it. Duh. You can use the output as-is when copy-and-pasting. No need to manually add extra backspaces! That's pretty convenient, eh? This really had me confused me at first, though, because I am so used to the behavior of Chrome's console, which prints out the unescaped string values (even though it does put quotes around the value).

$ node
> "\ "
' '
> JSON.stringify("\ ")
'" "'
> "\\"
'\\'
> JSON.stringify("\\")
'"\\\\"'
> new Buffer("\\")
<Buffer 5c>
> new Buffer([0x5c]).toString()
'\\'
> new Buffer([0x5c, 0x5c]).toString()
'\\\\'

2012-02-29

U+2665 BLACK HEART SUIT

I was reading an article on StackOverflow when one of the ads caught my eye. It looked something like this:

1
2
3
4 <p>
5 &#x2665;
6 Your Job
7 </p>
8
9

"What character is that?" I wondered whilst automatically opening up the in-browser console.

> String.fromCharCode(0x2665)
""

Hey, it's the U+2665 BLACK HEART SUIT! So, that would make the message: ♥ Your Job.

Cool.

2012-01-06

Tomcat v6.0.35 and UTF-8 Parameters

Update 1 (2012-01-07): I don't have access to the problematic system right now and am unable to confirm; but, when I tried simplifying this down to just one JSP, it worked fine. It also worked fine with one mayaa file. This leads me to think that there must be some system-specific issue.

The recent release of Apache Tomcat, v6.0.35, seems to break the handling of parameters encoded in UTF-8. For example, if I pass "%E6%97%A5%E6%9C%AC" (which is the string of URL-escaped UTF-8 bytes for "日本"), it gets incorrectly interpreted. Both URIEncoding="UTF-8" and useBodyEncodingForURI="true" are set for the necessary Connectors in server.xml, and it works as expected prior to v6.0.35.

Expected:
$ cat nippon && cat $_ | hexdump -C
日本
00000000  e6 97 a5 e6 9c ac 0a                              |.......|
00000007

Actual:
$ cat tomcat-bug && cat $_ | hexdump -C
æ¥æ¬
00000000  c3 a6 c2 97 c2 a5 c3 a6  c2 9c c2 ac 0a           |.............|
0000000d

I cloned the GitHub mirror of tomcat60 and did a quick git-bisect. The offending commit is 1ef4156 (r1200601 in SVN), which corresponds to the last two items of the Catalina changelog for unreleased version 6.0.34.

So, in other words, Tomcat properly interprets parameters prior to (and fails starting from) 1ef4156.

It is hard to tell exactly what the problem is, though, because 1ef4156 is such a large commit. My best guess, without digging into the code, is that ISO-8859-1 is being used instead of UTF-8 in the decoding process—i.e., it seems that the charset is not being correctly passed to the parameter processor.

The same "mistaken" decoding can be done with iconv, as follows:
$ cat nippon | iconv -f ISO-8859-1 -t UTF-8 | hexdump -C
00000000  c3 a6 c2 97 c2 a5 c3 a6  c2 9c c2 ac 0a           |.............|
0000000d

Maybe I'll have a look later and try to fix the problem.

2011-10-08

Different fetch/push URLs for git clone

UPDATE 1
It turns out to be reeeeallly easy!
git remote set-url --push origin git@example.com:username/repo.git


I always use passphrases on my ssh keys. Everyone does, right? Anyway, it gets kind of annoying entering it in each time when fetching from an upstream repository. I don't have enough need to set-up a key-ring, though. So, I took a quick look at git config --help and figured out how to set-up different URLs for git-push and git-fetch.
remote.<name>.url
    The URL of a remote repository. See git-fetch(1) or git-push(1).
remote.<name>.pushurl
    The push URL of a remote repository. See git-push(1).

I just opened up .git/config and set remote.origin.url to the read-only URL, and remote.origin.pushurl to the initial value of remote.origin.url.

Now, I can git-fetch/git-pull without the annoying passphrase prompt. Yay.

There's probably a way to do it with git-remote; but, I'm too lazy to figure it out right now...