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

[Dmitry Gutov <dgutov@yandex.ru>]

On 09/19/2014 05:22 PM, Eli Zaretskii wrote:

> For you.  Then someone else will come and argue that Gnus or Org or
> whatever buffers are much more important.

They'd be welcome to justify that importance with prolific contributions 
of code.

>> I'd like to reiterate here, that I'd be satisfied just with some
>> instructions how to convert the current `posn-col-row' return value
>> into value that respects text scale.
>
> I still don't understand enough what that means to answer, sorry.  See
> below.

What I had in mind, is instead of dividing the pixel coordinates by 
`frame-char-width', first scale it according to the text scale level.

> The distinction is this: do you need the column to access text in the
> same display line, or do you need it for other display lines, like for
> aligning text in the next or previous lines with the text of the line
> where you called posn-col-row?

I don't think it would help: before the column number is used, the 
contents of the next (or previous) lines get converted to "plain" text 
to the best of our ability: tabs are converted to spaces, for example.

>> But from `posn-col-row' I actually take the screen column value
>
> And do what with it?  Please be specific, and please don't spare me
> the details.  I don't have your knowledge of what company-mode does to
> answer these questions myself, and I have only a very vague idea of
> how you arrange the display of the completion candidates and how the
> "column" reported by posn-col-row enters that picture.

I think I've described it already in previous discussions. e.g. in 
http://debbugs.gnu.org/18195

For better description, you could just read the code, starting with 
`company-pseudo-tooltip-show'. I think it's pretty easy to follow, and I 
won't have to translate it line-by-line from Elisp to English.

> E.g., given arbitrary pixel coordinates, posn-at-x-y will give you the
> object at those coordinates and character position within that object.
> Is that what you need?

Not really: for example, if there's a tab character there, the value 
will be too imprecise (I need to know the exact column inside the tab). 
Or if there's an existing overlay there, I'd try my best to ignore it. 
"character position" within its display string won't help me in the least.