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: Tue, 07 May 2013 19:50:51 +0300 Message-ID: <83ip2uentg.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> <83bo8of4hp.fsf@gnu.org> <51885853.7020803@yandex.ru> <83txmfebzp.fsf@gnu.org> <5188B00C.2080600@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1367945479 9026 80.91.229.3 (7 May 2013 16:51:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 May 2013 16:51:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 07 18:51:17 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 1UZl6e-0002ZJ-HY for ged-emacs-devel@m.gmane.org; Tue, 07 May 2013 18:51:12 +0200 Original-Received: from localhost ([::1]:33458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZl6e-0008NO-7g for ged-emacs-devel@m.gmane.org; Tue, 07 May 2013 12:51:12 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZl6a-0008LZ-CP for emacs-devel@gnu.org; Tue, 07 May 2013 12:51:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZl6Y-0005Q5-P2 for emacs-devel@gnu.org; Tue, 07 May 2013 12:51:08 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:59395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZl6Y-0005Pm-H0 for emacs-devel@gnu.org; Tue, 07 May 2013 12:51:06 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MMF00400TDY8E00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 07 May 2013 19:50:58 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MMF001VGTGXYTA1@a-mtaout22.012.net.il>; Tue, 07 May 2013 19:50:58 +0300 (IDT) In-reply-to: <5188B00C.2080600@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:159397 Archived-At: > Date: Tue, 07 May 2013 11:41:00 +0400 > From: Dmitry Gutov > CC: emacs-devel@gnu.org > > On 07.05.2013 6:54, Eli Zaretskii wrote: > >> One might think that `move-to-window-line' is also window-relative and > >> thus agnostic to the header line (that naturally follows if we consider > >> the header line a part of the window). > > > > "Line" is a line of text, and move-to-window-line was written to go to > > a line of text. > > The question is how they're numbered. One might imagine that the > "zeroth" line is covered by the header, so the first one visible is > number one. But you cannot move point to the header line. And argument of zero to move-to-window-line already has a different meaning. > >> We still need to compare the column values to see if the click happened > >> exactly inside the rectangle, not to the right or left of it. > > > > Doesn't the overlay cover the entire rectangle? > > > >> And in `company-select-mouse', we need the row values to find out which > >> rectangle line was clicked (which candidate to select) > > > > Isn't each rectangle a different string? > > > > There's just one overlay, and it covers all of them (plus all text on > the sides). Sorry, I don't understand. Perhaps we are talking about two different things. Are you talking about the menu-like display of possible completions, shown to the user to let her select one of the candidates? If so, how can they be a single overlay string, when they are shown in different screen lines? Are you also copying the buffer text into the overlay string or something? Otherwise I don't understand how can you show a multi-line overlay string and still have buffer text be seen. What am I missing? > Maybe what you're suggesting would be an improvement (I see > dropdown-list.el also does that), but the current approach works fast > enough, and it would have the advantage in a hypothetical situation when > some of the text we need to "draw on" is already rendered via `display' > property. I don't see any advantages even in that situation, but maybe I'm misunderstanding what you mean. My suggestion is to make each completion candidate a separate display string, then the event position list will tell you directly which string was clicked. > I mean fixing the row number <-> line number discrepancy from the other > side, by making a wrapper for `move-to-window-line', the only function > of the bunch that deals with line numbers. It's used in > `company-pseudo-tooltip-show'. count-screen-lines also deals with line numbers. Anyway, I think you now have the information needed to fix company.el, and can select the implementation that you like best.