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

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

[Keith David Bershatsky]

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

Thanks,

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

In GNU Emacs 25.1.50.4 (x86_64-apple-darwin10.8.0, NS appkit-1038.36 Version 10.6.8 (Build 10K549))
 of 2016-02-21 built on server.private
Repository revision: 5a0472e8ea9128f75bca04f5f65682ae8280c208
Windowing system distributor 'Apple', version 10.3.1038
Configured using:
 'configure --with-ns --without-imagemagick --enable-checking=glyphs
 CPPFLAGS=-I/Users/HOME/.0.data/.0.emacs/macports/include
 LDFLAGS=-L/Users/HOME/.0.data/.0.emacs/macports/lib'

Configured features:
JPEG RSVG DBUS NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LANG: en_US
  locale-coding-system: utf-8-unix

Major mode: ELISP

Minor modes in effect:
  ys-mode: t
  tabbar-mode: t
  sb-mode: t
  ml-mode: t
  ds-mode: t
  sd-mode: t
  fl-mode: t
  +-mode: t
  buffer-read-only: t

Recent messages:

Load-path shadows:
None found.

Features:
(shadow emacsbug message mml mml-sec epa epg mm-decode mm-bodies
mm-encode gmm-utils mailheader sendmail lawlist-ztree lawlist-ys
lawlist-ws lawlist-wl elmo-imap4 elmo-localdir modb-standard
modb-legacy elmo-internal elmo-flag mmelmo-imap mmelmo-buffer
elsp-generic mel-u epg-config lawlist-w3m doc-view jka-compr
image-mode ccl lawlist-vl lawlist-view lawlist-undo lawlist-txt
lawlist-tm lawlist-tex compare-w diff-mode lawlist-tabbar
lawlist-speedbar lawlist-shell info esh-groups ehelp ange-ftp
lawlist-sgml lawlist-sb lawlist-ruler lawlist-replace
lawlist-rectangle lawlist-re-builder lawlist-python skeleton
lawlist-profiler lawlist-print lawlist-php lawlist-perl lawlist-parens
lawlist-org lawlist-calendar org-agenda org org-macro org-footnote
org-pcomplete org-list org-faces org-entities org-version
ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src
ob-keys ob-comint ob-core ob-eval org-compat org-macs org-loaddefs
find-func holidays hol-loaddefs cal-menu calendar cal-loaddefs
lawlist-neotree lawlist-movement lawlist-mouse lawlist-ml lawlist-misc
lawlist-messages lawlist-mc lawlist-markdown noutline outline
lawlist-lorem lawlist-linum lawlist-keymap lawlist-js json map
thingatpt cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs lawlist-ispell lawlist-isearch
lawlist-info lawlist-imenu lawlist-ibuffer lawlist-hl lawlist-grep
lawlist-git pcvs-util ido seq server conf-mode lawlist-framebufs
lawlist-frame lawlist-fm lawlist-env lawlist-elscreen lawlist-elisp
lawlist-dv lawlist-image lawlist-files zeroconf dbus xml lawlist-ds
lawlist-dired dired dired-loaddefs format-spec lawlist-diff
lawlist-desktop frameset lawlist-saveplace lawlist-debug
lawlist-window debug lawlist-css smie lawlist-compile rx lawlist-color
lawlist-cm lawlist-cc-mode lawlist-cc-awk lawlist-font-lock cl-macs
lawlist-cc-fonts lawlist-cc-guess lawlist-cc-menus lawlist-cc-align
lawlist-cc-cmds lawlist-cc-styles lawlist-cc-engine lawlist-cc-langs
lawlist-cc-vars lawlist-cc-defs lawlist-cc-bytecomp lawlist-calc
lawlist-calc+ lawlist-bk lawlist-bc lawlist-bbdb gnus nnheader subr-x
wid-edit mail-parse rfc2231 mailabbrev mail-extr rfc822 timezone
lawlist-minibuffer gv lawlist-auth gnus-util rmail rmail-loaddefs
rfc2047 rfc2045 ietf-drums mail-utils mm-util mail-prsvr
password-cache lawlist-as lawlist-archive lawlist-apropos lawlist-+
lawlist-lcl byte-opt bytecomp byte-compile cl-extra cconv lawlist-help
disp-table easy-mmode edmacro kmacro quail help-mode easymenu
cl-loaddefs cl-lib pcase derived advice shell pcomplete comint
ansi-color ring savehist time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win
ucs-normalize term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
minibuffer cl-preloaded nadvice loaddefs button faces cus-face
macroexp files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
dbusbind kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
nil

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

[Eli Zaretskii]

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

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

[Keith David Bershatsky]

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.

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

[Keith David Bershatsky]

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.

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

[Eli Zaretskii]

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

bug#22757: Reply to correspondence dated February 22, 2016.

[Keith David Bershatsky]

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.

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

[Keith David Bershatsky]

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.

bug#22757: Reply to correspondence dated February 22, 2016.

[Eli Zaretskii]

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

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

[Keith David Bershatsky]

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

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

[Lars Ingebrigtsen]

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