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

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.

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

[Eli Zaretskii]

> 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.

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

[Stefan Monnier]

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

Yikes!  I hate it when an application moves my mouse.


        Stefan "Reminds me that I have to figure out why Emacs sometimes
                moves my mouse"

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

[Drew Adams]

> > 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.)

Good to know.  Yes, it would be good for the differences to be made
clear in the doc - esp. wrt use cases.

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

[Eli Zaretskii]

> Date: Thu, 18 Sep 2014 10:12:40 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: dgutov@yandex.ru, 18493@debbugs.gnu.org
> 
> > > 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.)
> 
> Good to know.  Yes, it would be good for the differences to be made
> clear in the doc - esp. wrt use cases.

I fixed the doc string.

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

[Drew Adams]

> 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.

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

[Eli Zaretskii]

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

You are being carried away, and probably also influenced by the
"usual" meaning of "column" and "row".  What posn-col-row returns are
not arbitrary random values it finds around the block.  It returns
precise coordinates in units of canonical character size.  These
values are useful because there are functions in Emacs that expect
them.

So, while it is meaningless to talk about "columns" and "rows" in
their usual meanings, it is still meaningful to talk about coordinates
measured in canonical character cell units.

> The case of text scaling seems to me to be a case where we can
> meaningfully return the visual column and row.

In my other mail I wrote that the buffer position is all you need for
that, and you already have it.  So I see no general problem here,
unless someone shows a particular use case where that is not enough
for some reason.  Then we can reason whether what's needed is
"scalable" variant of posn-col-row or something else.

> And if `posn-actual-col-row' really does return the actual, visual
> column and row

It doesn't.  posn-actual-col-row is just an accessor function to some
of the data in the click event.  See the discussions I pointed to.

> So let me ask you that same question: what is the use case that the
> current design supports?

Just grep the Lisp files for that function, there are several dozens
of its uses throughout Emacs (and a few more in C).

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

They do 2 very different things.

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

[Dmitry]

1. M-x text-scale-increase (7 times)
2. Go to column 4.
3. (posn-col-row (posn-at-point))
=> (15 . 24)

Alternatively, please describe how to reliably recalculate the returned
value in the presence of text-scale-mode.

In GNU Emacs 24.3.93.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2014-09-05 on axl
Repository revision: 117482 monnier@iro.umontreal.ca-20140904161426-2072ebabqpyhaadw
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

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

[Drew Adams]

> 1. M-x text-scale-increase (7 times)
> 2. Go to column 4.
> 3. (posn-col-row (posn-at-point))
> => (15 . 24)
> 
> Alternatively, please describe how to reliably recalculate the
> returned value in the presence of text-scale-mode.

I don't even understand why the value should change with text scale.
What part of the description of `pos-col-row' would lead one to think
that this changes with text scale?

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

[Dmitry Gutov]

On 09/18/2014 02:53 AM, Drew Adams wrote:

> 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.

> What part of the description of `pos-col-row' would lead one to think
> that this changes with text scale?

Probably none. Do you have code that calls `posn-col-row', though? Is it 
aware of `posn-col-row' not being affected by text scale? Does it have 
explicit support for text scaling?

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

[Drew Adams]

> > 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.

I don't understand why the value changing helps, instead of hurts,
in that context.  I would think that the column should not change
just because the text is scaled.  But I'm probably missing something.

> > What part of the description of `pos-col-row' would lead one to
> > think that this changes with text scale?
> 
> Probably none. Do you have code that calls `posn-col-row', though?

It doesn't matter whether I do or don't.  As a matter of fact, I do,
but only a little bit - 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.

> Is it aware of `posn-col-row' not being affected by text scale?

I guess you mean *being* affected by it (?).  IIUC, the return
value depends on the text scale.  Isn't that the bug you reported?

That's the bug I see (though someone will no doubt explain why
they think it is TRT).

> 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...

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

[Dmitry Gutov]

On 09/18/2014 05:56 AM, Drew Adams wrote:

> I don't understand why the value changing helps, instead of hurts,
> in that context.  I would think that the column should not change
> just because the text is scaled.  But I'm probably missing something.

Take a look at the implementation. The function takes pixel coordinates 
and divides them by the frame-default character dimensions. 
text-scale-mode is buffer-local, so it doesn't change the latter.

> It doesn't matter whether I do or don't.  As a matter of fact, I do,
> but only a little bit - 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.

That was my point.

>> Is it aware of `posn-col-row' not being affected by text scale?
>
> I guess you mean *being* affected by it (?).  IIUC, the return
> value depends on the text scale.  Isn't that the bug you reported?

Indeed. By "not affected", I just meant that the implementation doesn't 
take it into account.

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

[Drew Adams]

> > I don't understand why the value changing helps, instead of hurts,
> > in that context.  I would think that the column should not change
> > just because the text is scaled.  But I'm probably missing
> something.
> 
> Take a look at the implementation. The function takes pixel
> coordinates and divides them by the frame-default character dimensions.
> text-scale-mode is buffer-local, so it doesn't change the latter.

Yes, I guessed that.  That sounds like the wrong behavior, to me.
The frame char size is not useful here, I would think.  What counts,
for visual _columns_ is the visual char size, i.e., from text scaling.

IOW, I don't see why scaling is not taken into account when
calculating the position in column terms.  But what do I know?
I'm just asking what the rationale or use case is behind this behavior.

> That was my point.

Yes, I gathered that.  Dunno whether we are saying the same thing
or not.  I'm questioning whether the frame char size or the
text-scale char size should be used, to define what "columns" are
here.

I would think the latter.  But I haven't tried to think this
through carefully.  Perhaps there are other considerations
motivating this design, which have not occurred to me.

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

[Eli Zaretskii]

> Date: Thu, 18 Sep 2014 08:37:21 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> > > I don't understand why the value changing helps, instead of hurts,
> > > in that context.  I would think that the column should not change
> > > just because the text is scaled.  But I'm probably missing
> > something.
> > 
> > Take a look at the implementation. The function takes pixel
> > coordinates and divides them by the frame-default character dimensions.
> > text-scale-mode is buffer-local, so it doesn't change the latter.
> 
> Yes, I guessed that.  That sounds like the wrong behavior, to me.
> The frame char size is not useful here, I would think.  What counts,
> for visual _columns_ is the visual char size, i.e., from text scaling.

Perhaps in the case of text scaling, it does (and even then there are
reasons for the current behavior, see my other mail).

But text scaling is just one particular feature that Emacs display
supports; there are many more where it is meaningless to talk about
"columns".  E.g., how do you measure an inline image in columns? what
would be the "column" of the first character displayed after such an
image?  What about stretches of whitespace created by the likes of
':align-to' display properties -- how do you measure them in
"columns" in some useful and predictable manner?

Either we want a general solution, or something for "simple" use
cases.  The former is not possible, as I hope you will agree; the only
general solution is to use pixel coordinates.  The "simple" solution
we already have, it just doesn't go far enough to cover text scaling,
and it will take some serious arguments and real-life use cases to
convince me that we should go farther or introduce a new API for those
use cases.

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

[Eli Zaretskii]

> Date: Wed, 17 Sep 2014 18:56:10 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> > Probably none. Do you have code that calls `posn-col-row', though?
> 
> It doesn't matter whether I do or don't.  As a matter of fact, I do,
> but only a little bit - 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?

> > 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.  posn-col-row
just converts that to the frame's canonical character units, that's
all.  We have other functions which map that to buffer position or to
other objects if the click event is not on buffer text.  The question
is what you do with what posn-col-row returns.  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.

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

[martin rudalics]

 > Alternatively, please describe how to reliably recalculate the returned
 > value in the presence of text-scale-mode.

`posn-actual-col-row'?

martin

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

[Dmitry Gutov]

On 09/18/2014 01:32 PM, martin rudalics wrote:
>  > Alternatively, please describe how to reliably recalculate the returned
>  > value in the presence of text-scale-mode.
>
> `posn-actual-col-row'?

It works for row number, but it's not good enough for column number, 
because it doesn't take character widths into account (mostly a problem 
with tab characters).

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

[Eli Zaretskii]

> From: Dmitry <dgutov@yandex.ru>
> Date: Thu, 18 Sep 2014 02:03:46 +0400
> 
> 1. M-x text-scale-increase (7 times)
> 2. Go to column 4.
> 3. (posn-col-row (posn-at-point))
> => (15 . 24)

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.  There's no bug here.

> Alternatively, please describe how to reliably recalculate the returned
> value in the presence of text-scale-mode.

Calculate what, exactly?  The results of this function _are_ reliable.
You just cannot in general use them as the logical (a.k.a. "physical")
column and row number, i.e. the ordinal number of a character from the
line beginning and its line number relative to window-start.  You can
only use them as the real column and row if your text uses the default
face.  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.

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".

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

[Dmitry Gutov]

On 09/18/2014 06:58 PM, Eli Zaretskii wrote:

> 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.  There's no bug here.

Fair enough. Maybe define an alternative function, which does take  text 
zoom into account?

Or otherwise, I'd be fine with precise algorithm how to convert one into 
the other, if it's relatively simple and unlikely to change.

> Calculate what, exactly?  The results of this function _are_ reliable.
> You just cannot in general use them as the logical (a.k.a. "physical")
> column and row number, i.e. the ordinal number of a character from the
> line beginning and its line number relative to window-start.  You can
> only use them as the real column and row if your text uses the default
> face.  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.

Text zoom is different from all the other features you enumerate here, 
though. In programming language buffers, I usually have no images or 
proportional fonts, but zooming the text is something that happens once 
in a while.

> So the answer to your question depends on what you intend to do with
> the value.

All the recent display engine issues I've been creating are for the same 
package and feature: company-mode and its overlay-based popup, which I'd 
like to polish up a bit before trying other methods of popup rendering, 
because they won't be available to users of Emacs 24.4 and older 
versions, and it'll likely be quite some time until the next release.

> IOW, please explain what is it that "you'd like".

The "current column" obtained from the return value of this function, is 
used to position each line of the popup in the display string of the 
overlay that spans the next few lines. So naturally, the return value 
should not depend on the zoom level. And I'm using `posn-col-row' for 
this because it became the consensus in the several discussions I've had 
with you recently on this subject.

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

[Stefan Monnier]

> Fair enough. Maybe define an alternative function, which does take  text
> zoom into account?

To tell you the truth, I don't know what that means.  "Text zoom" is
just one particular case of the use of faces to change the size of text.
So do you want the alternative function to only handle text-zoom
(i.e. remapping of the `default' face, so the face applies to
"everything"), or do you want it to handle the more general case where
every glyph might have different size?

If the former, than it'll just be another ad-hoc hack.


        Stefan

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

[Dmitry Gutov]

On 09/19/2014 05:05 AM, Stefan Monnier wrote:
> So do you want the alternative function to only handle text-zoom
> (i.e. remapping of the `default' face, so the face applies to
> "everything"), or do you want it to handle the more general case where
> every glyph might have different size?
>
> If the former, than it'll just be another ad-hoc hack.

Yes, the former. Maybe so.

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

[Eli Zaretskii]

> Date: Fri, 19 Sep 2014 00:55:06 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18493@debbugs.gnu.org
> 
> On 09/18/2014 06:58 PM, Eli Zaretskii wrote:
> 
> > 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.  There's no bug here.
> 
> Fair enough. Maybe define an alternative function, which does take  text 
> zoom into account?

I'm not yet sure what that other function should do.  See below.

> Text zoom is different from all the other features you enumerate here, 
> though. In programming language buffers, I usually have no images or 
> proportional fonts, but zooming the text is something that happens once 
> in a while.

Is company-mode only for buffers whose major mode is some programming
language?  I thought it was more broad.  But even if it is only for
programming languages, does it mean that the API you wish existed
should only cater to such modes?

> The "current column" obtained from the return value of this function, is 
> used to position each line of the popup in the display string of the 
> overlay that spans the next few lines.

So what you actually need is to find the correct X coordinate for the
screen line _below_ (and maybe also above) the one where posn-col-row
is called, is that right?

If so, first question is why not do all this in pixels?

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

[Dmitry Gutov]

Eli Zaretskii <eliz@gnu.org> writes:

> Is company-mode only for buffers whose major mode is some programming
> language?

I'd say it's the first priority.

> I thought it was more broad.  But even if it is only for
> programming languages, does it mean that the API you wish existed
> should only cater to such modes?

It's hard to say. Maybe? 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.

> So what you actually need is to find the correct X coordinate for the
> screen line _below_ (and maybe also above) the one where posn-col-row
> is called, is that right?

I don't understand the distinction. But from `posn-col-row' I actually
take the screen column value (the row value returned from
`posn-actual-col-row' is more useful).

> If so, first question is why not do all this in pixels?

Because we use the returned value when combining the display string for
the overlay. So at some point the pixels have to get converted to
character numbers, and we're back to the same problem.

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Cc: 18493@debbugs.gnu.org
> Date: Fri, 19 Sep 2014 15:17:09 +0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is company-mode only for buffers whose major mode is some programming
> > language?
> 
> I'd say it's the first priority.

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

> 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.

> > So what you actually need is to find the correct X coordinate for the
> > screen line _below_ (and maybe also above) the one where posn-col-row
> > is called, is that right?
> 
> I don't understand the distinction.

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?

> 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.

> > If so, first question is why not do all this in pixels?
> 
> Because we use the returned value when combining the display string for
> the overlay. So at some point the pixels have to get converted to
> character numbers, and we're back to the same problem.

I still don't understand this well enough, please give the details.

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?

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

[Dmitry Gutov]

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.

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

[Eli Zaretskii]

> Date: Fri, 19 Sep 2014 22:08:14 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18493@debbugs.gnu.org
> 
> >> 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.

You describe a means to get what you want, but don't explain why you
need that.  Why do you need to divide the pixel coordinates by
something?  What do you want to achieve by that division?  What are
you going to do with the 'scaled" column?

> >> 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

If that were enough, I wouldn't be asking for more details.

> For better description, you could just read the code

Sorry, I don't have time for that.

I don't insist that you explain things to me, I'm trying to help you
find the way of computing whatever it is that you need.  Feel free to
give up on me.

> > 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). 

That can be computed.

> 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.

Not sure what you mean by "ignore", but the value tells you that you
have a string there, so you can do whatever you want.

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

[Dmitry Gutov]

On 09/19/2014 11:46 PM, Eli Zaretskii wrote:

 > You describe a means to get what you want, but don't explain why you
> need that.  Why do you need to divide the pixel coordinates by
> something?  What do you want to achieve by that division?

Then I'll have the return value of `posn-col-row' dependent on the 
buffer contents, but hopefully independent of the text scale level.

> I don't insist that you explain things to me, I'm trying to help you
> find the way of computing whatever it is that you need.  Feel free to
> give up on me.

Thank you, but you seem intent on helping me write the code in a 
considerably different way than it's written now. That would indeed be a 
waste of time, like Stefan said, because it mostly works well enough.

Closing.

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

[Stefan Monnier]

> It's hard to say. Maybe? 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 think this is all a waste of time.  We should focus on company popups
based on GUI elements (most likely special kinds of frames) rather than
based on overlay-hacks.  That will work with any random crap you might
have in the buffer (scaled text, proportional fonts, images, you name
it).  The current overlay approach can be kept for the tty case, where
proportional fonts, images, and such things don't exist anyway.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  18493@debbugs.gnu.org
> Date: Fri, 19 Sep 2014 10:54:15 -0400
> 
> > It's hard to say. Maybe? 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 think this is all a waste of time.  We should focus on company popups
> based on GUI elements (most likely special kinds of frames) rather than
> based on overlay-hacks.

Dmitry asked for help in solving a problem, and I'm trying to do that.
We already agreed that posn-col-row works as advertised, so this is
not about changing code.  AFAIK, no one intends to work on what you
suggest any time soon (and I agree that doing what you suggest is the
right way forward).

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

[Dmitry Gutov]

On 09/19/2014 07:43 PM, Eli Zaretskii wrote:

>> I think this is all a waste of time.  We should focus on company popups
>> based on GUI elements (most likely special kinds of frames) rather than
>> based on overlay-hacks.
>
> Dmitry asked for help in solving a problem, and I'm trying to do that.
> We already agreed that posn-col-row works as advertised, so this is
> not about changing code.  AFAIK, no one intends to work on what you
> suggest any time soon (and I agree that doing what you suggest is the
> right way forward).

Like explained earlier, since the GUI element-based popups are unlikely 
to work in Emacs 24.4 and older, and the next release is almost 
certainly 6-12 months away, I've been trying to add some polish for the 
users of current Emacs.

But indeed, the text zoom issue is of no critical importance, so feel 
free to close this issue, of you like.

(I do intend to start tinkering with the GUI-based popups relatively 
soon, by the way).

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

[Stefan Monnier]

> Like explained earlier, since the GUI element-based popups are unlikely to
> work in Emacs 24.4 and older, and the next release is almost certainly 6-12
> months away, I've been trying to add some polish for the users of
> current Emacs.

posn-col-row can't "take text-scale-mode into account".  So the only way
forward would be to provide another posn-something-col-row, and that
is not an option for 24.4.  So if you want it to work with 24.4 it'll have
to be based on what's already present.

I think you can make it work in Company by simply taking a copy of
posn-col-row into company.el and changing it so that it multiplies
frame-char-width and frame-char-height by the current text-scaling factor.

It's very brittle, but it's not like there's a much better solution out
there anyway (other than using a GUI-based popup, I mean, of course).


        Stefan

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

[Dmitry Gutov]

On 09/20/2014 05:17 AM, Stefan Monnier wrote:

> I think you can make it work in Company by simply taking a copy of
> posn-col-row into company.el and changing it so that it multiplies
> frame-char-width and frame-char-height by the current text-scaling factor.

Thanks, I'll consider that.