From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#29279: Sharing the margins Date: Mon, 13 Nov 2017 21:02:23 +0200 Message-ID: <56131da6-14fb-d669-f69a-72fd2e696d5c@yandex.ru> References: <0a54e927-cab1-1f1d-4996-85bb36949a33@yandex.ru> <834lpymbga.fsf@gnu.org> <83po8mkptj.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1510599820 10807 195.159.176.226 (13 Nov 2017 19:03:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 19:03:40 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 Cc: 29279@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 13 20:03:36 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 1eEK16-0002TI-Nk for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 20:03:32 +0100 Original-Received: from localhost ([::1]:55942 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEK1E-0006qv-4O for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 14:03:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33917) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEK0f-0006bL-Ti for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 14:03:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEK0c-0006x6-Qc for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 14:03:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58401) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eEK0c-0006x2-ML for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 14:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eEK0c-00055V-EH for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 14:03:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Nov 2017 19:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29279 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29279-submit@debbugs.gnu.org id=B29279.151059975519514 (code B ref 29279); Mon, 13 Nov 2017 19:03:02 +0000 Original-Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 19:02:35 +0000 Original-Received: from localhost ([127.0.0.1]:38848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEK0B-00054f-5J for submit@debbugs.gnu.org; Mon, 13 Nov 2017 14:02:35 -0500 Original-Received: from mail-wr0-f180.google.com ([209.85.128.180]:49083) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEK09-00054J-Ru for 29279@debbugs.gnu.org; Mon, 13 Nov 2017 14:02:34 -0500 Original-Received: by mail-wr0-f180.google.com with SMTP id 15so15340235wrb.5 for <29279@debbugs.gnu.org>; Mon, 13 Nov 2017 11:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CGvbCtbdz3k1sQGBWsQjbRGvmuq1DzdRMWxXIQOyYb8=; b=EfEtKAeyw+i4DQLugoyGOEoT6uCrngVOEZL7TZk6jhQP7HMia+slDiIatOArM0AYtn ImYXU/nawJ4l5rOQ9TA82rao+svqKveVBZe8/QtZ+vJaUGvYk67DAZLzYVk4HIJtE7Ty ev6/Z5/uY8OAkkYLxbVQNf4P3XnHSYkmvKiKjyge1BxWWtSc15unCzS9rp1IJcv+uSuc 1+8WbzfxDuHHHgyrzvDykhIBA1oKxUlpVLT5wBXlq2sW2xr1nflLDP2AeMebAoKigg/s H1MIHTMfgof7nUiI3cFZti1Va3435Lkg7hbp0MmyR8FjbjhMYDPQ3Ast9OmLJVPXWe0E RWvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CGvbCtbdz3k1sQGBWsQjbRGvmuq1DzdRMWxXIQOyYb8=; b=JiCrf1JMIafgdRVdmFofa5naFSw3GdvD+tGa57jHO/ihz/134Ym5aA0QHdX//RAWe9 biEb9bzupBUym/HowE+rIeoO1grFm1DagZtLoB0KAcmQ3dYQaGnBs9GxUFlCnebP7b9I USRldFm28v5wWrSeRDq9YHHl8uCShQJQqw6MLt6ZrBfUS68YJRIQIXbZ50aRgytABc5C U62rj1mtQ/hjUcPr3xyoJML8+wI8gbLmT50+EbCUgIFuwtfqHzKWpK7ZU+GYtb8xCKv1 skol32YjsqXD+duJaSnaZQVlwm7RbrJn3eI2jQBHR8HJLCQDysK9IyFGBhj/hkMSyaPG P6oA== X-Gm-Message-State: AJaThX5uEvsyBNktlQYvdWvdRAgI1I5K/X2ON+P8emxkTpohHyMZ+FjS rXiEiOx4NmkrFHq4C1+TZV0dIhYq X-Google-Smtp-Source: AGs4zMZ1UavA4QSnUQTn5VZPNHtO3yjgUqPxlscNY4Nqu8NxZ8isRHklmHYLXPyIbzRceLqmkcJ5RQ== X-Received: by 10.223.198.130 with SMTP id j2mr8321272wrg.52.1510599747581; Mon, 13 Nov 2017 11:02:27 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id e124sm4924760wmg.34.2017.11.13.11.02.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 11:02:25 -0800 (PST) In-Reply-To: <83po8mkptj.fsf@gnu.org> Content-Language: en-US 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:139843 Archived-At: On 11/13/17 8:15 PM, Eli Zaretskii wrote: > No, to the left. If a Lisp program wants to align to the right, it > should insert white space before the actual text. That's only possible if it knows the resulting width. Which it will, in the current state of the discussion. Still, it seems unnecessary if the somewhat faster C code could implement that for every user. >>>> The display engine would scan the contents of the current window, process said specs, calculate which lines fit the window and which do not, set the total margin width appropriately, and display all columns in it. Some reflowing might be required. > > If everything is already spelled out in a variable > left-margin-columns-alist, then why do we need to scan the contents of > the window? In the first proposal, the actual width of the column would be auto-computed by the display engine based in the width of all relevant SPECs. But we seem to have discarded this idea now. >> I was hoping that we might consider some parts of redisplay to be "fast >> enough" by now (posn-at-point is fast enough for ~500 FPS on my machine, >> for instance), but indeed it should require some smart programming. > > posn-at-point goes _once_ from window-start to the specified position, > so on average it traverses half a window, once. By contrast, we are > now talking about redisplaying the window twice, and one of these 2 > times must traverse the entire window. So we are talking about > threefold slow-down on the average. 3-fold slowdown from 500 FPS seems acceptable to me. > So yes, if the margin display depends heavily on what is in the > window, especially on how many lines/characters are in the window, it > will have hard time being Speedy Gonzales; such features are better > implemented in C as an integral part of redisplay. But not all uses > of the margins are like that. I will even risk saying that most of > them aren't. For that majority, calculating the maximum width they > need from the margin at the end of a command is not a big deal, and > could probably change relatively rarely. Let's hope so.