bug#16557: 24.3; foreground-color-at-point does not define a color produced by facemenu-set-foreground

bug#16557: 24.3; foreground-color-at-point does not define a color produced by facemenu-set-foreground

[Alex Kost]

Recipe:
- emacs -Q
- Create new buffer (lisp-interaction-mode is not suitable):
  C-x b new RET
- Write some text and select it
- M-x facemenu-set-foreground RET green RET
- The text becomes green, but "M-: (foreground-color-at-point)"
  returns nil 

I see problems both in `foreground-color-at-point' / `background-color-at-point'
and `facemenu-add-face' (the root function for facemenu functions like
`facemenu-set-foreground' or `facemenu-set-background').

1. `foreground-color-at-point' / `background-color-at-point'

According to (info "(elisp) Special Properties") a `face' property can
be a face name, a property list or a list of faces, i.e. a list of face
names or a list of property lists.  But `foreground-color-at-point' and
`background-color-at-point' do not support the latter form.

If you update a face property of some text
like this (create a new buffer and write something there):

  M-: (put-text-property (point-min) (point-max) 'face '(:foreground "green"))

then (foreground-color-at-point) gives the right answer - "green".  But
if you make a *list* of property lists:

  M-: (put-text-property (point-min) (point-max) 'face '((:foreground "green")))

then (foreground-color-at-point) returns nil.

2. `facemenu-add-face'

This function produces even a more nested form.  After "M-x
facemenu-set-foreground RET green RET" on some selected text, move the
point to any green character and "M-: (get-text-property (point) 'face)"
will return (((:foreground "green"))).


In GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.10.6)
 of 2014-01-18 on mnt-storage-buildroots-staging-i686-eric
Windowing system distributor `The X.Org Foundation', version 11.0.11500000
Configured using:
 `configure '--prefix=/usr' '--sysconfdir=/etc' '--libexecdir=/usr/lib'
 '--localstatedir=/var' '--with-x-toolkit=gtk3' '--with-xft'
 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fstack-protector
 --param=ssp-buffer-size=4'
 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'
 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

bug#16557: 24.3; foreground-color-at-point does not define a color produced by facemenu-set-foreground

[Lars Ingebrigtsen]

Alex Kost <alezost@gmail.com> writes:

> Recipe:
> - emacs -Q
> - Create new buffer (lisp-interaction-mode is not suitable):
>   C-x b new RET
> - Write some text and select it
> - M-x facemenu-set-foreground RET green RET
> - The text becomes green, but "M-: (foreground-color-at-point)"
>   returns nil 

(This bug report unfortunately got no response at the time.)

Thanks for the clear recipe.

I tried reproducing this in Emacs 28, but `foreground-color-at-point'
returns "green" for me there, so I'm going to go ahead and guess that
this problem has been fixed at some point after this bug was reported,
and I'm closing this bug report.

If you're still seeing this issue, please respond to the debbugs address
and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16557: 24.3; foreground-color-at-point does not define a color produced by facemenu-set-foreground

[Alex Kost]

Lars Ingebrigtsen (2020-12-06 15:51 +0100) wrote:

> Alex Kost <alezost@gmail.com> writes:
>
>> Recipe:
>> - emacs -Q
>> - Create new buffer (lisp-interaction-mode is not suitable):
>>   C-x b new RET
>> - Write some text and select it
>> - M-x facemenu-set-foreground RET green RET
>> - The text becomes green, but "M-: (foreground-color-at-point)"
>>   returns nil 
>
> (This bug report unfortunately got no response at the time.)
>
> Thanks for the clear recipe.
>
> I tried reproducing this in Emacs 28, but `foreground-color-at-point'
> returns "green" for me there, so I'm going to go ahead and guess that
> this problem has been fixed at some point after this bug was reported,
> and I'm closing this bug report.
>
> If you're still seeing this issue, please respond to the debbugs address
> and we'll reopen.

I also don't reproduce it anymore :-)
Thank you for the reply!

-- 
Alex