From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov 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 07:38:43 +0400 Message-ID: <518725C3.10107@yandex.ru> References: <83mxcyuw60.fsf@gnu.org> <87haiiqwiz.fsf@yandex.ru> <83vc6yf8hr.fsf@gnu.org> <5185CB24.5060207@yandex.ru> <83sj21fmo5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1367811538 24463 80.91.229.3 (6 May 2013 03:38:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 May 2013 03:38:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 06 05:38:57 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 1UZCGP-0006IR-6w for ged-emacs-devel@m.gmane.org; Mon, 06 May 2013 05:38:57 +0200 Original-Received: from localhost ([::1]:56446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZCGO-0001Ed-LQ for ged-emacs-devel@m.gmane.org; Sun, 05 May 2013 23:38:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZCGH-0001EN-S5 for emacs-devel@gnu.org; Sun, 05 May 2013 23:38:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZCGD-0001Yw-NG for emacs-devel@gnu.org; Sun, 05 May 2013 23:38:49 -0400 Original-Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:37047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZCG9-0001YK-8c; Sun, 05 May 2013 23:38:41 -0400 Original-Received: by mail-la0-f53.google.com with SMTP id eo20so2962805lab.12 for ; Sun, 05 May 2013 20:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=kNOkICp6ZyJwlMTL2Pc9+TKvY05Tj6v1TzQNW3is0Mo=; b=JASfDjrK+OuXmcvfhqeLL4JHRueT5n6e4ft2++5Oz1i2tQ9lFBxuJx5fSuVqBKBikC ePUo6j06HZ88Axyc7GG7A9cPbfsPMSFJIpy3p4wXQZfSamaeSS70WAhdUTr19ouxeUVu xFtxb7leEYIdhJ0KRt+ELCUzn4YfSVnrejLnmb4bAgGg1FGZZqZR5DZdnfZT16QopsUR s1pd9o2aq/Ud1LbeeumVAHA6dgFj33kBdi0MeJGjfnRLB7tAVDO+pY8/cIaN+AjinAAt 4DKLd1G84eYTnqTeFoDojaCwBEzWaf3HRY0lOiaO/mg12sxZUw2QG5TsDwn3q3785Ees Es7g== X-Received: by 10.112.131.68 with SMTP id ok4mr6282918lbb.78.1367811519850; Sun, 05 May 2013 20:38:39 -0700 (PDT) Original-Received: from [127.0.0.1] ([178.252.98.87]) by mx.google.com with ESMTPSA id 2sm4256152lay.5.2013.05.05.20.38.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 May 2013 20:38:37 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: <83sj21fmo5.fsf@gnu.org> X-Antivirus: avast! (VPS 130505-1, 05.05.2013), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::235 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:159359 Archived-At: On 05.05.2013 19:53, Eli Zaretskii wrote: >> Date: Sun, 05 May 2013 06:59:48 +0400 >> From: Dmitry Gutov >> CC: emacs-devel@gnu.org >> >>>> 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 >> 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. >> 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. https://raw.github.com/company-mode/company-mode/master/company.el `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.