In this case, I would assume that only modifies how text is displayed in 
the ncurses window.

<tab><content>
becomes:
<><content>
not:
<tab><cont

Funny thing is that the behavior is really anomalous. If I open the same 
email again, the tabs are working fine.

Excerpts from Mark Alexander's message of 2010-01-27 16:57:33 -0500:
> I've been noticing this problem for a long time now.
> I think it happens with tabs anywhere in the
> message, or perhaps at the beginning of lines,
> but I haven't played with it enough to know for sure.

Sup assumes that 1 codepoint == 1 screen cell. This also causes problems
with double-width Chinese(?) characters. William has suggested using
wc[s]width, and now that we've got our own fork of ncurses-ruby we might
as well stick it in there. I looked at it briefly and iirc the
troublesome part was getting a wchar_t from the bytes in a Ruby string.

Tabs are funny because their width depends on their position. I say
replace all tabs with 2 spaces before calling ncurses.

Anirudh Sanjeev, 2010-01-27 23:11:
> Steps to reproduce:
> 1. Compose message with a tab as a first character
> 2. View composed message in the compose-mode

Looks like tabs are counted as 1 (instead of 8) when calculating
string display width.  Dunno why this did not affect thread-view-mode
thought.  Patch attached.

I've been noticing this problem for a long time now.
I think it happens with tabs anywhere in the
message, or perhaps at the beginning of lines,
but I haven't played with it enough to know for sure.

Steps to reproduce:
1. Compose message with a tab as a first character
2. View composed message in the compose-mode

It looks like this in my text editor:
http://imgur.com/NH2Rz.png

Here's how it looks like in compose mode. Note how the last few characters of
the compose mode is truncated.
http://imgur.com/xdL0U.png