Comment 7 for bug 616828

Uday Reddy writes:
 > > Yes, it would mean that existing customization would change, but
 > > I'd argue this can be justified. The current setup does not allow
 > > a user to customize the face other than to set it to an already
 > > defined face. Making it a propper face definition will allow much
 > > more standard and flexible customization.
 >
 > But the user can define a new face and set the variable to that
 > face. So, I don't see a limitation.
 >

True, but defining a face is not as easy as using the custom interface to
change the attributes of an existing face. Not all VM users are comfortable
with writing elisp and even those that are often have problems getting face
definitions correct.

 > The VM documentation makes a big deal of the fact that VM uses face
 > variables rather than faces themselves. So, there is likely to be
 > quite a big hooplah if we make a change like this.
 >

Except now VM uses both faces and face variables. This has the risk of causing
confusion. I'm already concerned there will be confusion with
vm-summary-highlight-face and vm-summary-selected face. In fact, long-term, we
probably should consider making vm-summary-selected always active (ie. not just
when you have vm-summary-enable-faces set to t and removing
vm-summary-highlight-face as they appear to do the same thing. This wold
simplify/reduce some of the code.

I will send a post to the newsgroup and vm-info list and see how
people feel about the change. Maybe that will provide us with better data to
guage the impact.

Tim

--
Tim Cross
<email address hidden>

There are two types of people in IT - those who do not manage what they
understand and those who do not understand what they manage.