GNU bug report logs - #13686
24.3.50; Re-look hi-lock-face-defaults (aka Provide more "core" faces for highlighting)

Previous Next

Full log

Message #92 received at 13686 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: David Koppelman <koppel <at> ece.lsu.edu>
Cc: Jambunathan K <kjambunathan <at> gmail.com>, Drew Adams <drew.adams <at> oracle.com>,
	13686 <at> debbugs.gnu.org
Subject: Re: bug#13686: hi-yellow vs. hi-lock-1
Date: Fri, 08 Mar 2013 20:33:15 -0500

>> hi-lock-N
>> highlight-N
>> font-lock-user-N
>> font-lock-highlight-N
>> font-lock-extra-face-N

The "font-lock-<foo>" names are due to history.  There's no point using
this scheme for new faces, especially for faces not directly linked to
font-lock.

> As for the convention of not naming or otherwise linking a face with
> particular attributes (as some may interpret it), either it doesn't
> apply here, or if it does, it's a good place to ignore it. I've argued
> before that it does not apply because as most agree faces should be
> defined for a particular purpose rather than for appearance, such as
> for highlighting variable names. The face hi-yellow has a purpose:
> highlight something with a background of yellow. It is named
> appropriately and its attributes are so set. If there is a rule
> somewhere which clearly states that this is not allowed, then that
> rule should be broken in this case.

How 'bout designing a concise "face description" format, so that instead
of choosing "hi-yellow", the user can choose (say) "b:yellow",
"f:blue", or "s:bold".  This would give access to "any color", and in
order not to overwhelm the user, the completion would default to only
completing among a predefined set (corresponding to the current
predefined faces)?


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.