From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup Date: Wed, 28 Jun 2017 21:56:38 +0300 Message-ID: <83o9t8q6u1.fsf@gnu.org> References: <611468a0-3115-813a-7347-d0c06e155831@web.de> <83vanrx5uo.fsf@gnu.org> <362a7d18-7f05-2e99-f8b3-41c353cf234f@yandex.ru> <83h8zawvih.fsf@gnu.org> <00f59a24-2d80-ca47-b6f3-3d219aa5aa3f@yandex.ru> <8360fqvz9x.fsf@gnu.org> <6aa4616d-79f7-db1b-c048-076a9a48596f@yandex.ru> <83tw39urzq.fsf@gnu.org> <4c4b873b-2bec-1c12-82f5-325b558bea93@yandex.ru> <83o9tgul6h.fsf@gnu.org> <49b431fd-aaa4-e7ca-06fc-7146a0a5692c@yandex.ru> <83a84zul0d.fsf@gnu.org> <513eca6f-998a-a937-76c4-7cf2fb0ff787@yandex.ru> <83wp81u8rz.fsf@gnu.org> <8ec1b301-79dc-7d11-b3f9-85ae2e925785@yandex.ru> <594FDDC5.6040009@gmx.at> <83zicwrkmu.fsf@gnu.org> <5950C342.7010908@gmx.at> <83mv8ussb6.fsf@gnu.org> <595203DE.1040608@gmx.at> <837ezxsd02.fsf@gnu.org> <59527971.5000205@gmx.at> <83y3sdqtto.fsf@gnu.org> <59536CA6.10608@gmx.at> <83r2y4qcs1.fsf@gnu.org> <5953F706.7080405@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1498676298 26086 195.159.176.226 (28 Jun 2017 18:58:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Jun 2017 18:58:18 +0000 (UTC) Cc: alexanderm@web.de, 27427@debbugs.gnu.org, dgutov@yandex.ru To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 28 20:58:14 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQIAC-0006Ik-1U for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Jun 2017 20:58:08 +0200 Original-Received: from localhost ([::1]:35228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQIAH-0002p1-3l for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Jun 2017 14:58:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQIAA-0002og-Nw for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 14:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dQIA6-0006HG-IE for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 14:58:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40322) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dQIA6-0006HA-FE for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 14:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dQIA6-0002s2-9d for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 14:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Jun 2017 18:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27427 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27427-submit@debbugs.gnu.org id=B27427.149867623010975 (code B ref 27427); Wed, 28 Jun 2017 18:58:02 +0000 Original-Received: (at 27427) by debbugs.gnu.org; 28 Jun 2017 18:57:10 +0000 Original-Received: from localhost ([127.0.0.1]:42999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQI9G-0002qx-JQ for submit@debbugs.gnu.org; Wed, 28 Jun 2017 14:57:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47983) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQI9E-0002ql-OK for 27427@debbugs.gnu.org; Wed, 28 Jun 2017 14:57:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dQI95-0005hh-Aq for 27427@debbugs.gnu.org; Wed, 28 Jun 2017 14:57:03 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50465) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQI95-0005hd-7N; Wed, 28 Jun 2017 14:56:59 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2025 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dQI93-0004KC-Ve; Wed, 28 Jun 2017 14:56:58 -0400 In-reply-to: <5953F706.7080405@gmx.at> (message from martin rudalics on Wed, 28 Jun 2017 20:35:50 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133999 Archived-At: > Date: Wed, 28 Jun 2017 20:35:50 +0200 > From: martin rudalics > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > Alas, that is not how redisplay works. For starters, you seem to > > assume that it always traverses all the screen lines of a window (thus > > "on the next buffer line" etc.). But that is only so when a window > > needs a complete redisplay, and the display engine tries very hard to > > avoid that. Many times it only redraws some of the lines, sometimes > > just one line. If that line is not the first line of the popup, how > > will the display engine know that at some previous buffer position > > there is an overlay? > > Because an application would include that very line in the 'tty-popup' > overlay BEG...END range and the display engine has to know how to handle > an overlay that spans multiple lines. Right? I cannot answer this question, it's too general. And doesn't company-mode use before- and after-strings, at least sometimes? Those have BEG and END the same value, so you must hit that position to know something's there. > Then consider the ‘tty-popup-frames’ list approach: It would have to > remember the start and end glyph matrix positions of the popup frame as > drawn the last time and if these intersect with what has been redrawn in > an optimized way then it would have to (1) restore the old contents of > the popup frame by the real buffer text, if necessary and (2) rewrite > popup frame parts, if necessary. That'll cause flickering, as users will see "incorrect" stuff momentarily visible until the popup is restored. Moreover, the "redrawn" part is in dispnew.c routines, called long after xdisp.c did its job. I think the only workable idea is to create a special kind of window that is not part of the usual window tree, and let the display engine consider those windows after the "normal" ones have been. Do popup frames need to support windows, mode lines, etc? Or are they more like tooltips -- one window and no decorations?