Advanced Search

Akatombo Web Log

Monday, September 11, 2006

Setting Default encoding in Mail.app

Since my menus are in English, Mail.app defaults to sending UTF-8 e-mails, but whenever people using Outlook Express(?) reply to my Japanese language mails it comes back as garbage unless they explicitly set the encoding.  This has been a big problem for me, so with some research I figured out how to set the default encoding to what it would be where my system wide preferences set to display menus in Japanese - ISO-2022-JP

Just open up your terminal and enter

defaults write com.apple.mail NSPreferredMailCharset “ISO-2022-JP”

Thursday, August 17, 2006

Entering Japanese in TextMate

One of the big problems with TextMate for me is the lack of ability to handle Japanese text correctly.  Anyone who uses it with Japanese will know what I’m talking about.  Japanese text entry can pretty much cause the application to freeze, though I find that tapping a combination of space, escape, and enter will eventually unstick it and insert a bunch of junk into my file, which I can then erase.  That is the biggest problem, and is the one for which I have found a partial solution.  The other problem is that it can’t seem to handle rendering the font correctly and every character starts halfway through the one proceeding it, making reading virtually impossible.

I’ll explain my half solution here and propose a possible hack that could make this work better and keep you from accidentally freezing your app when Mac OS X decides it is time to jump into Japanese entry mode without asking.

The half-solution

The solution is very simple: when you use find and replace window Japanese text is handled fine.  So hitting cmd-f before entering Japanese text, then cmd-a to select all, cmd-c to copy, cmd-w to close the find window, and cmd-v to paste the text into the document you were on at the insertion point gets Japanese text into the document without problem.  That may sound like a long list of keyboard shortcuts, but they are all natural, muscle-memory shortcuts for me and, I’d guess, for most power users.  Still it remains a pain in the posterior, and since no other applications require a workflow like this I end up with a Japanese-text-frozen text mate about half the time. There has to be a better way!

A proposal for the other half

I can think of a number of things that could be done to automate the workflow described above, but let me describe the one that seems to me most likely to be achievable through the use of existing tools (It may even be poossiblw with bundles though it was beyond me to figure out in the brief time I looked into it):

I envision some type of environment monitor that can be set on a per-app basis that would allow the firing of actions before certain actions when in certain environments.  This app would be configured as follows for text mate.  When in TextMate in an Asian-character input mode and the active window a document, a character producing keystroke would open up the find and replace dialog before sending the keystroke through.  When the active window is the find and replace dialog and in an Asian-character input mode, switching to an non-Asian-character input mode or hitting cmd-w would execute the following: cmd-a,cmd-c,cmd-w,cmd-v,switch input mode if that was what triggered the sequence.

This idea is a total kludge, but would certainly make my life easier.  Like I say, there are a ton of other ways to do pretty much the same thing (a find and replace document wouldn’t even have to be the external editor).  In addition you’d really want any selected text to be copied to the external editor, and a lot of other little niceties, but as it sounds like it will be quite a while until Allan even thinks about making TextMate handle Asian fonts, I need all the help I can get as soon as I can get it, so that I can quit jumping between editors.

Wednesday, July 26, 2006

I’m going to start with this today

Warm, Partly Cloudy, 100% Chance of Brain Rain via 43Folders

Keys to catching the brain rain:

• set aside 10 minutes, each and every day


• have pen and paper handy


• allow yourself the freedom to think crazy thoughts


• don’t worry if nothing really productive springs to mind right away


• periodically scan over your notes from these sessions as things may pop into your mind after they have “marinated” for a while


• if no ideas pop into your head pick a fun topic and doodle a bit


• use word association to get things rolling if you feel stuck e.g. thinking -> thoughts -> mind -> brainstorm -> brain rain

Saturday, July 01, 2006

cross browser mime type list

I’m looking for a list of the mime type provided by a browser on upload of different file types to use in some quick preliminary upload validation, but haven’t been able to find any.  I may end up having to make the list myself, but since I don’t have a machine handy at the moment for testing Windows browsers I’d like to avoid doing that.  Does anybody know of such a list?  Please leave a comment!

Thursday, June 22, 2006

The hazards of self-taught Dom Scripting

I just had one of the epiphanies so common in the life of a self-taught programmer.  These types of epiphanies seem to be much more common for me in Javascript than in other programming languages.  I’m talking, of course, of those moments when you realize that there is a much better and/or more intuitive way of doing something that you’ve always thought was really inconvenient, but had just accepted as the only way to do it.  People familiar with the technique you’ve discovered will be shocked that anyone could ever even have considered doing it the way you’ve done it, and you feel like an idiot.

Well, just in case there is anyone else out there who has been doing things the way I have been, I’m revealing my idiocy to the world.  I’m still relatively unskilled when it comes to dom scripting so if any of you have any tips, please let me know.  And now on to my embarrassing lack of knowledge:

Probably one of the most common I do in dom scripting is adding and removing elements to the dom tree (client side form validation and things like that).  Adding elements has been no problem though it often seems like I’m going through contortions to specify where to add things.  Removing things has always seemed wrong.  The only way I knew to clear an element was to set innerHTML to an empty string. 

targetElement.innerHTML = “”;

If you are familiar with innerHTML you’ll know that doing something that doesn’t actually remove the element, it just removes everything inside it.  So if the element you want to remove is alone inside a parent node you can remove the offending element altogether, but in a situation like:

<div><h2>the offending element</h2><p>Content we want to keep</p></div>

It it impossible to just remove the h2 element and leave the p tag in tact.  The best you can do it to remove the contents of the h2 element and end up with something like:

<div><h2></h2><p>Content we want to keep</p></div>

Which is not at all what we want.  I also knew of removeChild, which was fine when I could identify the both the parent of the node I wanted to remove, and the node I wanted to remove.  I also knew of parentNode, but somehow in the muddled swamp that is my brain the two concepts never found each other until today when I realized I can do this:

toClear = getElementById(’error’);
toClear.parentNode.removeChild(toClear);

Rereading this, I feel like I was way too excited about it, but it hit me like a bolt of lightning and made my life quite a bit easier today.  I hope it helps somebody else out somewhere down the line.