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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 18 Sep 2014 08:37:28 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: dgutov@yandex.ru, 18493@debbugs.gnu.org
> 
> > > 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)

Then you should be fine, because set-mouse-position expects _exactly_
the "column" and "row" that posn-col-row returns.  (Its doc string
could tell that more clearly, but I looked at the implementation.)

> > posn-col-row just converts [pixels] 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?

Because in many use cases this is exactly what you want to pass to
other functions, which expect that.

> So I guess I will need to use something like this:
> 
> (if (fboundp 'posn-actual-col-row)
>     (posn-actual-col-row ...)
>   (posn-col-row ...))

Not necessarily: posn-actual-col-row has its own quirks, see its doc
string and the discussions in bug #18384.

> But why?  Why wouldn't it be TRT to have `posn-col-row' return
> the visual column, i.e., compensate for text scaling?

Because in most cases you will not be able to do anything useful with
such a "column" that you cannot do with the buffer position that is
already available in the click event and in some other posn-*
functions.

> Is there an advantage in using frame char size for it instead?

The advantage, as I see it, is that many Emacs APIs expect such units.

Of course, this is just a guess: I didn't design that function and
didn't write its first versions.  But after hacking display-related
code for some time, it makes perfect sense to me.