bug#18493: 24.3.93; posn-col-row should take text-scale-mode into account

[Drew Adams]

> > getting the column of a mouse click, using:
> >  (car (posn-col-row (event-start event)))
> > And I guess that code must be broken wrt text scaling.
> > I didn't realize that.
> 
> As I wrote elsewhere, whether it is broken depends on what you do
> with the results.  E.g., if you deal with mouse clicks, the
> natural value to use is the underlying buffer position, not
> column/row.  What do you need the column for?

I pass the column and row to `icicle-raise-Completions-frame',
which calls (set-mouse-position (selected-frame) col row)

> > > Does it have explicit support for text scaling?
> >
> > No, my code does not.  From what I understand now, I guess it
> > needs to worry about that now.  Seems nuts that it should have to,
> > but my understanding is limited...
> 
> Welcome to the brave new world of variable-size characters and other
> Emacs display features that break the "normal" interpretation of
> "columns" and "rows".  The only reliable way of expressing screen
> coordinates in the general case is with pixel values.  

OK, I can understand that.

> posn-col-row just converts that to the frame's canonical
> character units, that's all.  

That's precisely the question raised in this thread (at least
by me, and I think maybe by Dmitry).  Why?  Why doesn't
(shouldn't) it take text scaling into account?  What's the
value of using the frame char size for calculating visual
columns in the presence of text scaling?

> We have other functions which map that to buffer position or
> to other objects if the click event is not on buffer text.

OK.  And I see that Martin pointed to `posn-actual-col-row'.
So I guess I will need to use something like this:

(if (fboundp 'posn-actual-col-row)
    (posn-actual-col-row ...)
  (posn-col-row ...))

That's not a problem for me.

But why?  Why wouldn't it be TRT to have `posn-col-row' return
the visual column, i.e., compensate for text scaling?  Is there
an advantage in using frame char size for it instead?

> The question is what you do with what posn-col-row returns.

See above.  I return the mouse pointer to the clicked position.

I do some stuff, redisplay the (updated list of) candidates in 
*Completions*, raise the frame showing *Completions*, optionally
move that frame to the display edge (if one-window-p, and
respecting a user option), and reposition the mouse pointer
where it was when clicked.

I do the last part because user actions on individual candidates
can intentionally call `select-frame-set-input-focus', which
can position the mouse pointer on a standalone minibuffer frame.
(And that is very unhandy.)

> Given the answer, it should be possible to tell you how to
> get at the information even when such advanced display
> features are in use, or maybe identify some missing Emacs
> functionality.

I guess the answer to that is the workaround code above.

I have no problem with doing that.  I still ask the question:
Why?  What is the advantage of disregarding text scaling here?  
Why/when would anyone who wants the column and row not want
the column and row wrt the apparent char size (e.g. due to
text scaling)?  Why/when would s?he instead want the column
and row as determined by the frame default char size?

Just asking.  Maybe there is a good reason (e.g. a use case).
So far, I don't see it.