Log in

No account? Create an account
29 October 2007 @ 09:51 pm
OSX Leopard terminal drops bce (back-color-erase)??  
So I'm checking out the new features in the OSX Leopard terminal. Tabs, great. Can actually draw Monaco 9 properly without tweaking the FontWidthSpacing to 1.003, check. Wait, what's this? ESC 2J no longer fills the screen with the background color? Who the hell writes a terminal application that doesn't use bce? Especially considering the previous version did. This terminal claims to be xterm. And xterm supports bce. Even the xterm terminfo on osx says it supports bce! (infocmp xterm | grep bce)

For a simple test of your terminal's bce-supportingness, type this:
python -c 'print "\x1b[44m\x1b[2J"'
Your whole screen should end up with a blue background.

Seriously, Apple: what's up? Is there some maximum amount of goodness that's allowed in Terminal.app, so after fixing all the other things, you had to balance it out with some additional sucktitude? Or maybe I'm missing something really obvious here?

PS: I should mention: this isn't just idle concern. It actually does break terminal apps. Most full-screen apps which draw a background color will now look wrong, because the background color will only appear under the actively drawn text. For a good example, try mutt.
(Anonymous) on December 16th, 2007 01:40 am (UTC)
very interesting, but I don't agree with you
(Anonymous) on February 11th, 2008 05:06 am (UTC)
Re: Idetrorce
Pity you don't agree with him, because he's right.
(Anonymous) on June 18th, 2008 09:44 am (UTC)
Downgrade back to 10.4's terminal.app
I couldn't figure out a way around this behavior so I'm using the Terminal from the previous OS. It seems like the user's background color choice trumps that of the application running within the terminal.
(Anonymous) on June 18th, 2008 09:46 am (UTC)
Re: Downgrade back to 10.4's terminal.app
Hmm, I may stand corrected. After a cursory test, it seems that using ddterm emulation does the right thing: