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

[Drew Adams <drew.adams@oracle.com>]

> That's the intended behavior: posn-col-row is documented to return
> the coordinates of its argument in canonical character units.  And
> that is what it does here.

Yes, but why?

> There's no bug here.

> But once variable-size fonts, stretch glyphs, images, and
> other display atrocities come into play, there's no meaningful way of
> talking about "columns" and "rows" that can be used as indices into
> the text.

If there is no meaningful way to talk about columns and rows then
a function that returns the column and row might as well run around
the block and then take a nap.

I understand your argument, I think.  But there is a difference
between saying (a) that we cannot know just what visual column/row is
involved in the general case, in the presence of the many possible
display considerations and saying (b) that we cannot do that in any
cases.

The case of text scaling seems to me to be a case where we can
meaningfully return the visual column and row.  No?  So that general
give-up argument disappears in this case.

Granted, there is another possible question: Why not have both, as
separate functions - IOW, what we apparently have now, with the 
presence of function `posn-actual-col-row'.  But why?  Is there
really a use case for obtaining what `posn-col-row' currently
returns in a text-scaling context?

And if `posn-actual-col-row' really does return the actual, visual
column and row, then what does that say about your general can't-do
argument above?  And if it does not really do that, then why does
it have that name "actual", and why does its doc give the impression
that it does really do that?

> So the answer to your question depends on what you intend to do with
> the value.
> 
> > > I don't even understand why the value should change with text
> > > scale.
> >
> > It would solve the problem of text-scale-mode being enabled in
> > buffers, where I'm getting inaccurate results from `posn-col-row'
> > because of that. And by "inaccurate", I mean different from the
> > ones I'd like.
> 
> Then perhaps you want posn-col-row-as-dgutov-likes-it, not posn-col-
> row ;-)
> 
> Seriously, though: it all depends on what you do with the results
> returned by this function.  And you didn't explain what that is, so
> it is hard to tell whether there is a problem, and if so, where.
> 
> IOW, please explain what is it that "you'd like".

I agree that the whole question of this design depends on the answer
to your question: what do you intend to do with the return values.

So let me ask you that same question: what is the use case that the
current design supports?  What do you imagine might be a use for
obtaining the frame-char column and row and not wanting the "actual"
column and row?

I am generally in favor of allowing for such differences, as users
are pretty clever at coming up with uses for them.  But here I don't
(yet) see it.  And presumably the designers had something in mind,
when they chose to return the column & row based on frame char size
even in the presence of scaling.

IOW, why have two separate functions, `posn-col-row' and
`posn-actual-col-row'?

It's just a question.  Knowing the design is as it is can help users
put the various functions to best use.