bug#22757: 25.1.50; `face-at-point` and `faces--attribute-at-point` -- add argument WINDOW-OR-BUFFER

[Eli Zaretskii <eliz@gnu.org>]

> 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.