bug#5721: Feature request: Function that returns absolute coordinates

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 14 Jul 2010 17:22:27 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> I think major motivation to use the absolute coordinate system is
>> to specify the frame location (OP's case), or to pass it to
>> external programs (the SCIM case).  "Absolute unscaled" one is more
>> suitable for such uses.

> I would imagine that for frame positioning, absolute scaled would be the 
> default, as top and left frame parameters should also be absolute
> scaled.

That would bring us coarser precision with respect to the frame
position.  If the scale factor is 2, then we cannot place a frame to a
position whose coordinate is an odd number (in absolute unscaled).

On Mac OS X, the window (in window system terminology) position should
be specified in the unscaled coordinate system even with non-indentity
scale factor.

> To pass absolute unscaled to an external program or to position on
> absolute unscaled a special functions would be needed.  But I don't
> think a function that gives window edges is the place to do that.

I doubt the OP still wants window edges in absolute coordinates
systems, once he knows simple offsetting is not sufficient in general
(i.e., with scale factor).

I'm thinking about an interface that is parallel to posn-at-x-y and
returns absolute unscaled coordinates instead of position information.

  (posn-at-x-y x y &optional frame-or-window whole)

  Return position information for pixel coordinates x and y.
  By default, x and y are relative to text area of the selected window.
  Optional third arg frame-or-window non-nil specifies frame or window.
  If optional fourth arg whole is non-nil, x is relative to the left
  edge of the window.

                                     YAMAMOTO Mitsuharu
                                mituharu@math.s.chiba-u.ac.jp