[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Setting term-default-fg-color/term-default-bg-color has no effect
From: |
Dan Nicolaescu |
Subject: |
Re: Setting term-default-fg-color/term-default-bg-color has no effect |
Date: |
Wed, 01 Aug 2007 19:28:40 -0700 |
Peter Povinec <pp_publiclists@yahoo.com> writes:
> > I tested your changes by setting term-default-fg-color to blue and
> > term-default-bg-color to red on an emacs run with -Q and comparing
> > with running various curses applications in M-x term and "xterm -fg
> > blue -bg red". The results are not the same.
> Please be specific: what applications and how were the results different?
I'd
> just like to know.
I tried "emacs -nw", all empty lines did not use term-default-bg-color.
> > The problem is that the screen is updated in a lot of places in
> > term.el not only term-handle-colors-array. So this could not have
> > worked correctly in emacs 21 either.
> That is quite possible. The patch I submitted was intended to merely remove
> the regression in functionality introduced in Emacs 22. I believe it does
> that and is useful on its own, whether additional color handling fixes are
> applied or not.
It's hard to call a regression replacing one type of broken
behavior with another type of just slightly different broken
behavior.
> > Given that AFAIK nothing else in emacs changes the default foreground
> > and background for a buffer, it's kind of hard to find a convincing
> > argument that such a feature is needed for term.el. It can probably be
> > done with some effort, but is it worth the added complexity? Not
> > sure...
> The additional complexity introduced by the patch is negligible. We can
look
> at what it would take to fix the other color related issues you have seen,
but
> if those existed in version 21, I'd say they are separate issues and should
be
> treated as such.
I only see 2 possible fixes for this: either a patch that makes
changing the default fg and bg for M-x term work correctly, or simply
removing this configurability for the user. Anything else seems to be
just busy work. As I said, I am inclined to believe that the right
thing to do is the latter.