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#29279: Sharing the margins Date: Mon, 13 Nov 2017 20:15:36 +0200 Message-ID: <83po8mkptj.fsf@gnu.org> References: <0a54e927-cab1-1f1d-4996-85bb36949a33@yandex.ru> <834lpymbga.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1510596982 23682 195.159.176.226 (13 Nov 2017 18:16:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 18:16:22 +0000 (UTC) Cc: 29279@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 13 19:16:17 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 1eEJHI-0005iH-I3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 19:16:12 +0100 Original-Received: from localhost ([::1]:55797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEJHP-0006gj-Vd for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 13:16:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEJHB-0006dI-FI for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 13:16:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEJH8-0007Dc-81 for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 13:16:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58365) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eEJH8-0007DW-5M for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 13:16:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eEJH8-0003xu-0k for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 13:16:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Nov 2017 18:16:01 +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.151059694015204 (code B ref 29279); Mon, 13 Nov 2017 18:16:01 +0000 Original-Received: (at 29279) by debbugs.gnu.org; 13 Nov 2017 18:15:40 +0000 Original-Received: from localhost ([127.0.0.1]:38812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEJGm-0003xA-Fo for submit@debbugs.gnu.org; Mon, 13 Nov 2017 13:15:40 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:54715) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEJGk-0003ww-Lf for 29279@debbugs.gnu.org; Mon, 13 Nov 2017 13:15:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEJGc-0006zB-4w for 29279@debbugs.gnu.org; Mon, 13 Nov 2017 13:15:33 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEJGc-0006z7-10; Mon, 13 Nov 2017 13:15:30 -0500 Original-Received: from [176.228.60.248] (port=2024 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eEJGb-0003ez-KD; Mon, 13 Nov 2017 13:15:29 -0500 In-reply-to: (message from Dmitry Gutov on Mon, 13 Nov 2017 19:24:21 +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:139837 Archived-At: > Cc: 29279@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 13 Nov 2017 19:24:21 +0200 > > >> - Text alignment within the column (left or right) > > > > Why does this need to be a separate property? We don't have anything > > like that for any other kind of text. > > IDK, why not? Will we always align to the right? No, to the left. If a Lisp program wants to align to the right, it should insert white space before the actual text. > > I think we need to agree on the model of the display in the margins. > > The fact that you use "columns" in your proposal hints that each > > "user" of the margin (a Lisp program which displays there) will have a > > separate "column" in the margin, and that column will be of the same > > pixel width for each screen line. > > Yes. > > > If this is the model, then it makes > > little sense to have different display specs regarding the "column" > > width for each buffer position where display in the margin is > > requested, because the resulting column width will be the same for all > > such displays. > > The width of the string inside the margin display specs can very, can't it? The width can change, but the column width will not change. That means the column width should be specified only once, not multiple times. > > If we specify these in each display spec, we are in > > effect wasting Lisp storage, and potentially also working against the > > fundamental design of the display engine (more about that below). > > Sorry, specify what? The margin display spec will continue to be > > ((margin column-name) spec) > > where SPEC is a text string, most of the time. I thought you wanted all the other parameters in the spec as well. But if you didn't mean that, then what kind of scanning and calculations are you talking about here: > >> 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? > > So what you suggest can only be implemented by displaying each window > > twice. On top of that, it will disable important redisplay > > optimizations, which refrain from examining all of the screen lines > > and the corresponding buffer text -- since you require to scan all of > > the display specs in the window to dynamically compute the margin > > dimensions. > > 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. > What your description tells me, foremost, is that it should be > impossible to "perfectly" make these decisions in Lisp, too. > > Like, what can linum-mode do? After scrolling, it would look at the > window-start, its height, and calculate the _approximate_ physical line > at the end of the window. linum uses window-end (which could be nil in some cases). window-end is updated by redisplay when it ends successfully. linum then updates the width of the window margins if needed, and updates all the overlays with line numbers, which triggers an immediate additional redisplay. That's why it is slow. 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. > I guess more accurately, it would disallow dynamic *sizing* of the > margins by the display engine. With the current design of the display engine, dynamic resizing is not a good idea. Any such resizing is painful: it requires throwing away the window's glyph matrices, reallocating them anew with the new dimensions, and then completely redrawing the entire window. It's expensive and should be avoided. > Column widths will be accessible for manipulation from e.g. > pre-redisplay-functions, but like described above, it doesn't seem like > choosing margin width precisely is feasible in Lisp, even in the use > case of showing line numbers. I think it's feasible in many cases. Linum and its ilk are a rare use case, although the resulting feature is very popular (which is why we now have the native line numbers).