Subject: Re: bug#29279: Sharing the margins

From: Dmitry Gutov <[email-masked]>
Date: Mon, 13 Nov 2017 21:02:23 +0200

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.