If anybody cares, here is how rxvt-unicode-3.8 implements HT characters now, plus some initial experience on the effects.
When rxvt-unicode-3.8 received a HT, it first calculates the tab movement (which is a relative cursor movement). *Iff* all characters skipped over are spaces with the same attributes as the first space, it will replace these spaces by a (very) wide tab character (which is easy to do in the way rxvt-unicode handles wide characters, so the code changes were limited to less than 15 lines within the scr_tab method). If any of the characters are not spaces, or if there are attribute changes (e.g. colour), it will only move the cursor. i.e. printf 'aaa\tbbb\n' will result in: aaaTTTTTbbb ^^^^^ one wide tab character While printf 'aaa\r\tbbb\n' will result in: aaa bbb In addition, some care is required when updating such wide tabs (i.e. when replacing the 3rd cell of the tab character by a normal character). Rxvt-unicode handles this similar to other wide characters: when part of a wide character is being overwrtten, the whole character is being replaced by spaces. (it seems xterm doesn't handle this case, so would need to be fixed there first). This seems to work rather fine, the only cases where the user sees an obvious chane is when the cursor is positioned on such a tab character (it will be very wide then, wich imho is correct but somewhat surprising). The only program where I could see this effect, however, is xjdic, which does very strange things when editing (like outputting tab characters at the end of the current line when deleting parts of the input :) -- The choice of a | -----==- _GNU_ | ----==-- _ generation Marc Lehmann +-- ---==---(_)__ __ ____ __ [EMAIL PROTECTED] |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE | |