From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bug#9782: 24.0.90; move-to-window-line not taking header line into account Date: Mon, 06 May 2013 19:38:26 +0300 Message-ID: <83bo8of4hp.fsf@gnu.org> References: <83mxcyuw60.fsf@gnu.org> <87haiiqwiz.fsf@yandex.ru> <83vc6yf8hr.fsf@gnu.org> <5185CB24.5060207@yandex.ru> <83sj21fmo5.fsf@gnu.org> <518725C3.10107@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1367858360 419 80.91.229.3 (6 May 2013 16:39:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 May 2013 16:39:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 06 18:39:18 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UZORa-00064J-FU for ged-emacs-devel@m.gmane.org; Mon, 06 May 2013 18:39:18 +0200 Original-Received: from localhost ([::1]:58398 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZORZ-0002HS-QC for ged-emacs-devel@m.gmane.org; Mon, 06 May 2013 12:39:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZORV-0002EG-KJ for emacs-devel@gnu.org; Mon, 06 May 2013 12:39:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZORR-0002ni-UW for emacs-devel@gnu.org; Mon, 06 May 2013 12:39:13 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:36803) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZORR-0002nO-MW for emacs-devel@gnu.org; Mon, 06 May 2013 12:39:09 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MMD00800Y1BT800@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 06 May 2013 19:38:37 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MMD008A9Y8AO330@a-mtaout22.012.net.il>; Mon, 06 May 2013 19:38:35 +0300 (IDT) In-reply-to: <518725C3.10107@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159376 Archived-At: > Date: Mon, 06 May 2013 07:38:43 +0400 > From: Dmitry Gutov > CC: emacs-devel@gnu.org > > >> 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 > >> users. > > > > 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. Perhaps we need to improve the documentation of the posn-* family of functions, then. It is important to keep in mind that this family serves mainly the mouse events, so its coordinate system is window-relative. The use of columns and rows there is just to measure in character units, rather than in pixels. But it is still window-relative and agnostic to the header line, like the mouse is. > `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'). I don't see company--inside-tooltip-p anywhere in today's ELPA company package, but anyway, why do you need to use coordinates to determine whether the mouse clicked on the pseudo-tooltip? The pseudo-tooltip is a display or overlay string, right? So the OBJECT part of the event's POSITION member will tell you whether you clicked on the string or not: if it's nil, the click is on some buffer text, but if it's the display string, the click was on that string. > 1) Using `move-to-window-line', `vertical-motion' and a counter. Actually, I think you want something like (count-screen-lines (window-start) (point)) And for the mouse, see the suggestion above.