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: Sun, 25 Jun 2017 21:36:51 +0300 Message-ID: <83y3sfsym4.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> <594FEE69.5010106@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 1498415899 14776 195.159.176.226 (25 Jun 2017 18:38:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Jun 2017 18:38:19 +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 Sun Jun 25 20:38:12 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 1dPCQE-0003Ij-HQ for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Jun 2017 20:38:10 +0200 Original-Received: from localhost ([::1]:43458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPCQH-0003Oa-UW for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Jun 2017 14:38:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPCQA-0003OV-0U for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2017 14:38:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPCQ6-0008Bv-PB for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2017 14:38:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34923) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dPCQ6-0008Bc-Lv for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2017 14:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dPCQ6-0001Zk-GC for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2017 14:38: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: Sun, 25 Jun 2017 18:38: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.14984158516020 (code B ref 27427); Sun, 25 Jun 2017 18:38:02 +0000 Original-Received: (at 27427) by debbugs.gnu.org; 25 Jun 2017 18:37:31 +0000 Original-Received: from localhost ([127.0.0.1]:37600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPCPa-0001Z2-T3 for submit@debbugs.gnu.org; Sun, 25 Jun 2017 14:37:31 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPCPY-0001Ym-Ik for 27427@debbugs.gnu.org; Sun, 25 Jun 2017 14:37:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPCPO-0007uv-P7 for 27427@debbugs.gnu.org; Sun, 25 Jun 2017 14:37:23 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPCPO-0007uq-LW; Sun, 25 Jun 2017 14:37:18 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3094 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dPCPM-0004Sq-9n; Sun, 25 Jun 2017 14:37:18 -0400 In-reply-to: <594FEE69.5010106@gmx.at> (message from martin rudalics on Sun, 25 Jun 2017 19:10:01 +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:133896 Archived-At: > Date: Sun, 25 Jun 2017 19:10:01 +0200 > From: martin rudalics > CC: alexanderm@web.de, 27427@debbugs.gnu.org > > > I'd rather think in terms of "submargins", one per "category", and > > having an alist of particular properties of each of those categories. > > Once we do that we should try to accommodate as much as possible in the > concept we provide and I think that having ‘follow-mode’ implemented by > the display engine would be quite valuable. So I would vote for a more > general solution that encompasses it as well. I think people who lobby for more extensive and flexible use of the margins underestimate the amount of work something like that will take. The current management of the margin display is exceedingly rudimentary. Most of the sophisticated layout stuff we have in the text area -- truncation and continuation markers, word-wrap, etc. -- all that doesn't exist there. And the cursor cannot enter the margins. Basically, we just put there glyphs until the available space is exhausted, and that's it. By contrast, you guys are dreaming about full-fledged additional "text areas" with all the features we now support in the single one we have. That's an entirely new ballpark game, although I agree that it's a natural generalization and extension of what we have. The problem is that the knowledge of the basic canvas geometry is hard-coded in many places in the display code, and all of them will have to be reworked. I think this would be a very good project and a significant progress for Emacs, so I'd welcome such a development. Just don't underestimate the magnitude of the task.