* bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER
2016-02-21 18:05 bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER Keith David Bershatsky
@ 2016-02-21 20:54 ` Eli Zaretskii
2016-02-21 21:23 ` Keith David Bershatsky
` (4 subsequent siblings)
5 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2016-02-21 20:54 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22757
> Date: Sun, 21 Feb 2016 10:05:33 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
>
> As a feature request, please consider adding an additional argument to `face-at-point` and `faces--attribute-at-point` to support WINDOW-OR-BUFFER with `get-char-property`; and, add that to the sections of code in said functions containing `get-char-property`. The doc-strings would need to be updated to explain the difference. The default would be BUFFER.
>
> It is sometimes useful to be able to obtain a face of an overlay that is associated with a particular window -- e.g., an active region that may be different in each window. The current functions do not have the ability to test for that occurrence because the third argument of `get-char-property` is always `nil`.
Why can't you call get-char-property directly? face-at-point is
nothing more than a thin wrapper around get-char-property, and most of
the wrapper code is about stuff you don't care about AFAIU from your
description.
Is there something I'm missing?
Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER
2016-02-21 18:05 bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER Keith David Bershatsky
2016-02-21 20:54 ` Eli Zaretskii
@ 2016-02-21 21:23 ` Keith David Bershatsky
2016-02-22 15:58 ` Eli Zaretskii
2016-02-21 21:23 ` Keith David Bershatsky
` (3 subsequent siblings)
5 siblings, 1 reply; 10+ messages in thread
From: Keith David Bershatsky @ 2016-02-21 21:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22757
I spent a few hours trying to figure out how to obtain face properties at various points (with no active region) when active region was covering up those areas in another window displaying the same buffer in a different frame (hidden visually behind other frames). It was even more complicated to track down because the default value of `highlight-nonselected-windows` is `nil` and I couldn't visually see what was happening. I eventually discovered that third argument to `get-char-property` and my dilemma was resolved. :)
Another helpful feature would be an optional argument for POINT so that a user does not need to goto that point in order to obtain the face(s).
Feature request #22757 *may potentially* save other people hours of debugging; and, I believe adding POINT and WINDOW-OR-BUFFER as optional arguments could be very useful by making the current functions more powerful/versatile.
BACKGROUND: I am working on converting to C (from Lisp) a custom `color-vector-calc` function that returns the three digit color code at a given point in a window. Now that I discovered the third argument to `get-char-property`, I have a working function in Lisp.
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
At Sun, 21 Feb 2016 22:54:07 +0200,
Eli Zaretskii wrote:
>
> * * *
>
> Why can't you call get-char-property directly? face-at-point is
> nothing more than a thin wrapper around get-char-property, and most of
> the wrapper code is about stuff you don't care about AFAIU from your
> description.
>
> Is there something I'm missing?
>
> Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER
2016-02-21 21:23 ` Keith David Bershatsky
@ 2016-02-22 15:58 ` Eli Zaretskii
0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2016-02-22 15:58 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22757
> Date: Sun, 21 Feb 2016 13:23:05 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
> Cc: 22757@debbugs.gnu.org
>
> I spent a few hours trying to figure out how to obtain face properties at various points (with no active region) when active region was covering up those areas in another window displaying the same buffer in a different frame (hidden visually behind other frames). It was even more complicated to track down because the default value of `highlight-nonselected-windows` is `nil` and I couldn't visually see what was happening. I eventually discovered that third argument to `get-char-property` and my dilemma was resolved. :)
>
> Another helpful feature would be an optional argument for POINT so that a user does not need to goto that point in order to obtain the face(s).
>
> Feature request #22757 *may potentially* save other people hours of debugging; and, I believe adding POINT and WINDOW-OR-BUFFER as optional arguments could be very useful by making the current functions more powerful/versatile.
Sorry, I don't think I follow. I asked whether calling
get-char-property directly, instead of going through face-at-point,
would have done the job you needed to do. I still think it would
have, even after reading your response.
My point is that I see no particular reason why users should try using
face-at-point in this situation. That function is not documented in
the ELisp manual, whereas get-char-property is. So I'm not sure why
we should consider adding an argument to face-at-point to support use
cases that seem to be already supported by get-char-property. Can you
clarify this aspect?
Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER
2016-02-21 18:05 bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER Keith David Bershatsky
2016-02-21 20:54 ` Eli Zaretskii
2016-02-21 21:23 ` Keith David Bershatsky
@ 2016-02-21 21:23 ` Keith David Bershatsky
2016-02-22 18:15 ` bug#22757: Reply to correspondence dated February 22, 2016 Keith David Bershatsky
` (2 subsequent siblings)
5 siblings, 0 replies; 10+ messages in thread
From: Keith David Bershatsky @ 2016-02-21 21:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22757
I spent a few hours trying to figure out how to obtain face properties at various points (with no active region) when active region was covering up those areas in another window displaying the same buffer in a different frame (hidden visually behind other frames). It was even more complicated to track down because the default value of `highlight-nonselected-windows` is `nil` and I couldn't visually see what was happening. I eventually discovered that third argument to `get-char-property` and my dilemma was resolved. :)
Another helpful feature would be an optional argument for POINT so that a user does not need to goto that point in order to obtain the face(s).
Feature request #22757 *may potentially* save other people hours of debugging; and, I believe adding POINT and WINDOW-OR-BUFFER as optional arguments could be very useful by making the current functions more powerful/versatile.
BACKGROUND: I am working on converting to C (from Lisp) a custom `color-vector-calc` function that returns the three digit color code at a given point in a window. Now that I discovered the third argument to `get-char-property`, I have a working function in Lisp.
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
At Sun, 21 Feb 2016 22:54:07 +0200,
Eli Zaretskii wrote:
>
> * * *
>
> Why can't you call get-char-property directly? face-at-point is
> nothing more than a thin wrapper around get-char-property, and most of
> the wrapper code is about stuff you don't care about AFAIU from your
> description.
>
> Is there something I'm missing?
>
> Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#22757: Reply to correspondence dated February 22, 2016.
2016-02-21 18:05 bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER Keith David Bershatsky
` (2 preceding siblings ...)
2016-02-21 21:23 ` Keith David Bershatsky
@ 2016-02-22 18:15 ` Keith David Bershatsky
2016-02-22 19:25 ` Eli Zaretskii
2016-02-22 18:17 ` Keith David Bershatsky
2016-02-22 19:46 ` Keith David Bershatsky
5 siblings, 1 reply; 10+ messages in thread
From: Keith David Bershatsky @ 2016-02-22 18:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22757
I agree that `get-char-property` is the key ingredient, and it would be prudent to steer users to that function. It does, however, require an advanced level of Lisp expertise to understand how to use it to achieve certain goals. I probably wouldn't have been able to figure out (in a reasonable period of time) how to get foreground/background at point without standing on the shoulders of others -- e.g., `foreground-color-at-point` and `background-color-at-point`.
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
At Mon, 22 Feb 2016 17:58:13 +0200,
Eli Zaretskii wrote:
>
>
> Sorry, I don't think I follow. I asked whether calling
> get-char-property directly, instead of going through face-at-point,
> would have done the job you needed to do. I still think it would
> have, even after reading your response.
>
> My point is that I see no particular reason why users should try using
> face-at-point in this situation. That function is not documented in
> the ELisp manual, whereas get-char-property is. So I'm not sure why
> we should consider adding an argument to face-at-point to support use
> cases that seem to be already supported by get-char-property. Can you
> clarify this aspect?
>
> Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#22757: Reply to correspondence dated February 22, 2016.
2016-02-22 18:15 ` bug#22757: Reply to correspondence dated February 22, 2016 Keith David Bershatsky
@ 2016-02-22 19:25 ` Eli Zaretskii
2022-02-03 20:51 ` bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER Lars Ingebrigtsen
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2016-02-22 19:25 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 22757
> Date: Mon, 22 Feb 2016 10:15:27 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
> Cc: 22757@debbugs.gnu.org
>
> I agree that `get-char-property` is the key ingredient, and it would be prudent to steer users to that function. It does, however, require an advanced level of Lisp expertise to understand how to use it to achieve certain goals. I probably wouldn't have been able to figure out (in a reasonable period of time) how to get foreground/background at point without standing on the shoulders of others -- e.g., `foreground-color-at-point` and `background-color-at-point`.
get-char-property gets you the face, and then face-foreground and
face-background (both documented in the ELisp manual) can be used to
get the colors.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER
2016-02-22 19:25 ` Eli Zaretskii
@ 2022-02-03 20:51 ` Lars Ingebrigtsen
0 siblings, 0 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-03 20:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Keith David Bershatsky, 22757
Eli Zaretskii <eliz@gnu.org> writes:
> get-char-property gets you the face, and then face-foreground and
> face-background (both documented in the ELisp manual) can be used to
> get the colors.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I think the conclusion here is that Emacs has the building blocks needed
here, and extending `face-at-point' wouldn't really make things that
much easier for people to implement things, so I'm therefore closing
this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER
2016-02-21 18:05 bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER Keith David Bershatsky
` (3 preceding siblings ...)
2016-02-22 18:15 ` bug#22757: Reply to correspondence dated February 22, 2016 Keith David Bershatsky
@ 2016-02-22 18:17 ` Keith David Bershatsky
2016-02-22 19:46 ` Keith David Bershatsky
5 siblings, 0 replies; 10+ messages in thread
From: Keith David Bershatsky @ 2016-02-22 18:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22757
Sorry, the last email had an automatically generated subject line that I use in my personal setup. Here is a fixed subject line.
I agree that `get-char-property` is the key ingredient, and it would be prudent to steer users to that function. It does, however, require an advanced level of Lisp expertise to understand how to use it to achieve certain goals. I probably wouldn't have been able to figure out (in a reasonable period of time) how to get foreground/background at point without standing on the shoulders of others -- e.g., `foreground-color-at-point` and `background-color-at-point`.
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
At Mon, 22 Feb 2016 17:58:13 +0200,
Eli Zaretskii wrote:
>
>
> Sorry, I don't think I follow. I asked whether calling
> get-char-property directly, instead of going through face-at-point,
> would have done the job you needed to do. I still think it would
> have, even after reading your response.
>
> My point is that I see no particular reason why users should try using
> face-at-point in this situation. That function is not documented in
> the ELisp manual, whereas get-char-property is. So I'm not sure why
> we should consider adding an argument to face-at-point to support use
> cases that seem to be already supported by get-char-property. Can you
> clarify this aspect?
>
> Thanks.
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER
2016-02-21 18:05 bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER Keith David Bershatsky
` (4 preceding siblings ...)
2016-02-22 18:17 ` Keith David Bershatsky
@ 2016-02-22 19:46 ` Keith David Bershatsky
5 siblings, 0 replies; 10+ messages in thread
From: Keith David Bershatsky @ 2016-02-22 19:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22757
Here is the custom function that I came up with, derived in part from `faces.el`, `color.el` and from Drew's color libraries.
(defun color-vector-calc (buffer-or-window pos fg-or-bg)
"Calculate the color vector of either :foreground or :background for the face at POS.
Sample usage: (color-vector-calc (selected-window) (point) 'foreground)
The first argument BUFFER-OR-WINDOW is used in the context of `get-char-property'.
The second argument POS is a user specified `point' somewhere in the buffer/window.
The third argument FG-OR-BG is a symbol of either 'foreground or 'background"
(let* (
(frame (selected-frame))
(+-default-face-fg
(face-attribute-specified-or (face-attribute 'default :foreground frame 'default) nil))
(+-default-face-bg
(face-attribute-specified-or (face-attribute 'default :background frame 'default) nil))
(faceprop
(or
(get-char-property pos 'read-face-name buffer-or-window)
(get-char-property pos 'face buffer-or-window)
'default))
(face
(cond
((symbolp faceprop) faceprop)
((and (consp faceprop) (not (keywordp (car faceprop)))
(not (memq (car faceprop) '(foreground-color background-color))))
(car faceprop))
(t ;; e.g., (:foreground yellow)
faceprop)))
(color
(cond
((and face (symbolp face))
(if (eq 'foreground fg-or-bg)
(face-attribute-specified-or (face-attribute face :foreground frame 'default) nil)
(face-attribute-specified-or (face-attribute face :background frame 'default) nil)))
((and (eq 'foreground fg-or-bg) (consp face))
(cond
((memq 'foreground-color face)
(cdr (memq 'foreground-color face)))
((memq ':foreground face)
(cadr (memq ':foreground face)))
(t +-default-face-fg)))
((and (eq 'background fg-or-bg) (consp face))
(cond
((memq 'background-color face)
(cdr (memq 'background-color face)))
((memq ':background face)
(cadr (memq ':background face)))
(t +-default-face-bg)))
(t
(if (eq 'foreground fg-or-bg)
+-default-face-fg
+-default-face-bg))))
(color-values
(cond
((member color '(unspecified "unspecified-fg" "unspecified-bg"))
nil)
((memq (framep (or frame (selected-frame))) '(x w32 ns))
(xw-color-values color frame))
(t
(tty-color-values color frame))))
(value
(mapcar
(lambda (x)
(let* (
(valmax
(cond
((memq (framep (or frame (selected-frame))) '(x w32 ns))
(xw-color-values "#ffffff" frame))
(t
(tty-color-values "#ffffff" frame))))
(+-valmax (float (car valmax))))
(/ x +-valmax)))
color-values)) )
(vconcat value)))
^ permalink raw reply [flat|nested] 10+ messages in thread