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: Tue, 07 May 2013 21:19:59 +0400 Message-ID: <518937BF.1070500@yandex.ru> 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> <83ip2uentg.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 1367947223 29130 80.91.229.3 (7 May 2013 17:20:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 May 2013 17:20:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 07 19:20:22 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 1UZlYr-0004Yr-MK for ged-emacs-devel@m.gmane.org; Tue, 07 May 2013 19:20:21 +0200 Original-Received: from localhost ([::1]:60088 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZlYr-0005a8-6g for ged-emacs-devel@m.gmane.org; Tue, 07 May 2013 13:20:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZlYh-0005ND-7f for emacs-devel@gnu.org; Tue, 07 May 2013 13:20:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZlYb-0007kX-V6 for emacs-devel@gnu.org; Tue, 07 May 2013 13:20:11 -0400 Original-Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:37229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZlYW-0007Ut-Fg; Tue, 07 May 2013 13:20:00 -0400 Original-Received: by mail-la0-f53.google.com with SMTP id eo20so836619lab.12 for ; Tue, 07 May 2013 10:19:59 -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=cSuNrbo0du0s5IEe+x7PjykgOwtagj4oEAk76j1sc6Q=; b=YnNwlgtSLvv1V5TkSuc3w68uzOCvgsLEGL/5+vulSI31/lBKe4OzktpsD5FM9mUOxi zMQYHDP51m8Q26hOfBOmyMu4oWqz/AEj8jnOwZZIOz54FVQ7veEKRefgrwu2Y93a4kgB MuiLZDk/+9WYLQWiMUOTfhrAqn8eu7uZJz6OPR0yseISaDAK8+YWVJQ3481cM7fau/N3 aaF5KKIwFeeMbiEtFYD1VbHW5BVHOYqLQObPPGYFKSDUvc6D4HKJZwuEKceIyd3dSyST 62NPGKyb4dsbXVmEXQdPVSLkaI5e4sTSU2VpA8aPbICUh6Ii1CnD4Ys1u2GguzsRkz8S p/ZQ== X-Received: by 10.112.190.6 with SMTP id gm6mr1475790lbc.41.1367947198973; Tue, 07 May 2013 10:19:58 -0700 (PDT) Original-Received: from [127.0.0.1] ([178.252.98.87]) by mx.google.com with ESMTPSA id y3sm10589038lby.12.2013.05.07.10.19.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 10:19:57 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: <83ip2uentg.fsf@gnu.org> X-Antivirus: avast! (VPS 130507-0, 07.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:159398 Archived-At: On 07.05.2013 20:50, Eli Zaretskii wrote: >> 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? Yes. Yes, the whole lines are copied, modified in the right place and then shown using `before-string' overlay property (the original text is hidden with `invisible' -> t). >> 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. If some of the lines in the middle of the modified region are doing freaky things with `display', `before-string', etc, it complicates our ability to position each overlay on the right column visually (`current-column' only considers physical characters, the "right" column may turn out to be inside a `before-string' string, stuff like that). Making one overlay spread over all those lines means we can pre-process all lines, only take the physical text (plus composed chars), and mostly disregard third-party overlays. > 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 understood that, thank you. It would indeed allow us to skirt the row <-> line issue, at the cost of pervasive changes in the code. >> 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. Yes, but that would be fixing the discrepancy from the other side, and then `company--row', reimplemented using `count-screen-lines', would conflict with row values from mouse events, so this will only work when we don't need to compare them (i.e. when using multiple overlays). > Anyway, I think you now have the information needed to fix company.el, > and can select the implementation that you like best. I guess so. Thanks for the discussion!