[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#9782: 24.0.90; move-to-window-line not taking header line into a

From: Dmitry Gutov
Subject: Re: bug#9782: 24.0.90; move-to-window-line not taking header line into account
Date: Mon, 06 May 2013 07:38:43 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5

On 05.05.2013 19:53, Eli Zaretskii wrote:
Date: Sun, 05 May 2013 06:59:48 +0400
From: Dmitry Gutov <address@hidden>
CC: address@hidden

Simply adjusting the row number for presence of `header-line-format'
won't do, because company strives to support Emacs 23 (and maybe even
22), and `post-actual-col-row' behavior was different before the
revision 106022.

But it's a seemingly reasonable piece of code, it worked, and your
change made it break in some peculiar special case important to some

That's not true.  It was not a peculiar special case. The function did
not behave according to its contract, and my change fixed that.

Comparing the descriptions of `move-to-window-line' and `posn-actual-col-row', it doesn't seem obvious that one considers the header line part of the window, and another doesn't. The words "row" and "line" are often synonymous in English.

So I thought you could suggest how that code could be written
better/faster/stronger instead.

Well, how about telling more about what you need to do, and in
particular why do you need to go to the place you go by row and
column?  Why not use posn-point, for example?  For that matter, why
not use buffer positions directly?

In short, we're painting a rectangle near point, using an overlay. So columns and rows are a natural way to think about the problem.

Historically, the overlay rectangle is called "pseudo-tooltip" here.


`company-pseudo-tooltip-show-at-point' passes the current row and column to `company-pseudo-tooltip-show', which collects are required lines and prepares the `before-string' for the overlay.

These two would be the easiest to convert to direct point manipulation, except for the detail that they calculate, use and store the beginning column in the overlay property, for use later.

`company--pseudo-tooltip-height' calculates the appropriate rectangle height, based on the current row and the inner height of the window.

`company--electric-do' (somewhat unrelated) calls `recenter' using the value returned by `posn-actual-col-row'.

`company-select-mouse' and `company--inside-tooltip-p' handle mouse interaction with the rectangle, comparing the coordinates of the mouse click with the coordinates and dimensions of the rectangle (some of them saved previously; the current row is again retrieved using `posn-actual-col-row').

To conclude, I see two alternative solutions, both require re-implementing `company-row':

1) Using `move-to-window-line', `vertical-motion' and a counter.

2) Call `posn-at-point' and `posn-actual-col-row' in `company--row' twice, for the current point, and for the point at the top of the window (use `move-to-window-line' here), then subtract.

`posn-at-point' is relatively slow already, so the second option seems to be the worst one.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]