I just noticed that hardware-keyboard mapped {, }, and ] symbols don't work for me if mapped to Shift+Fn+V, Shift+Fn+B, and Shift+Fn+M, respectively. Oddly, Shift+Fn+N mapped to [ works fine.

I have only barely used TxPad after this latest update, so I'm not sure if this was an issue on earlier versions. It may also only work for Shift+Fn+N because instead of ", I have a dead-double-acute (which converts to a " when combined with itself or a space) mapped to Fn+N.

Another thing: It seems that the proximity sensor is still polled when you're not using the editor (at least, when you're in the task switcher, and cover the proximity sensor, you can see in the TxPad window that the proximity-sensor triggered menu comes up anyway - since constant proximity sensor polling is a rather high energy waste, and you might leave an open instance of TxPad in the background while spending a prolonged amount of time reading up on documentation or just doing anything else, it would be nice if the proximity sensor was only polled when TxPad was the currently open window, and at the same time was actually visible (I.E. the screen wasn't off).

Other than that I really like this editor, and while I'm currently in the habit of using vi on my N900, I can easily see myself deferring to this when coding something actually complicated.

- Edit -

@ post two posts before this one - battery life will not be significantly effected regardless of color scheme - the kind of battery life savings you could get from different color schemes was if the screen's pixels could be made to turn off (I.E. not emit any light) when they're completely black - the N900's pixels don't do that, and "black" on the N900's screen is still not true black - as a result, the amount of energy used is either the same, or almost identical. The N900's screen also has a backlight which uses significantly more energy than the screen's pixels do, regardless of color. However, I DO like the option to change color scheme.