GNU bug report logs - #15900
24.3.50; foreground-color-at-point returns wrong results

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15900 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: bug#15900: 24.3.50; foreground-color-at-point returns wrong results
Date: Sun, 17 Nov 2013 06:35:03 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> > > IOW, why not test against a known list of properties that you want to
> > > leave alone, instead of digging into their color?
> > 
> > I think the missing information you didn't have is that this is a
> > general mode, it must work in any Emacs buffer.  w3m was only an example
> > - info, man, and gnus are others.  So, testing for hardcoded face or
> > property lists is not really an option.
>
> I still don't see why it isn't an option, even for a general-purpose
> mode.  The list of faces that need such special treatment must be
> quite short, and it can be a defcustom.

From the user's point of view, yes, it's an option.  But you mentioned
it saying it would be easier to realize in Lisp.  This is what I have:

(cl-some
 (lambda (face) (not (memq (face-foreground face nil t)
		      `(nil
			,(face-attribute 'default :foreground)
			"unspecified-fg" "unspecified-bg"))))
 (cl-mapcan (lambda (face-or-list) (if (facep face-or-list)
				  (list face-or-list)
				face-or-list))
	    (list
	     (get-text-property (point) 'face)
	     (get-text-property (point) 'font-lock-face))))

For your solution, I can use a different predicate, but would still have
to find all faces at point, no?  What do I miss?


Regards,

Michael.

Previous Next

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