bug#29279: Sharing the margins

[Dmitry Gutov <dgutov@yandex.ru>]

On 11/15/17 8:00 PM, Eli Zaretskii wrote:

>>> Yes, but "being the rightmost" might mean "being right next to the
>>> text", for whatever purposes.
>>
>> So far, I doubt it's going to come up as a real, hard requirement. But
>> we'll probably see.
> 
> I could think of something similar to overlay-arrow, only using the
> margin.  Such a feature will want the arrow to be as close to buffer
> text as possible.

Yeah, OK.

>> If not, let's put all padding on the outside and be done with that concern.
> 
> This is doable, but the implementation will be more complex.
> Remember: the display engine lays out stuff left to right.  So padding
> what's left after we are done with all of the "columns" is easy;
> padding _before_ requires that you either compute all the widths in
> advance, or that you come back after laying out the columns and insert
> the stretch before it, moving all the glyphs to the right.

Sounds straightforward to me. Since we know the sizes of all the columns 
in advance, we can just substract them from the target total width, and 
pad with the resulting number of spaces.

Having extra padding between columns (your original idea) would be more 
complex to implement, IIUC.

>>> Again, as long as the text-area dimensions didn't change, it could be
>>> argued that the hook shouldn't run.
>>
>> That's some creative nomenclature lawyering. :-)
> 
> It isn't.  It's just how the implementation works.

Still. To the user, the line numbers column is more like an extra margin 
than anything else.

Further, even though we have a separate accessor for its width 
(line-number-display-width), if a package depends on it and needs to 
draw something based on its value, it should want to be notified when 
there is a change (*). window-configuration-change-hook seems natural. 
Unless we have a separate hook for that?

>> OK then, what's the practical problem with saying that margins are also
>> part of "text-area dimensions"?
> 
> It's hard to implement.  window-configuration-change-hook currently
> runs from functions that change window dimensions or the buffer
> displayed in it; those never run inside redisplay.  What you (and some
> others) propose will have to run in the middle of redisplaying a
> window, and who knows what running arbitrary Lisp at that point will
> or could do?

Not necessarily. Can't you save the necessary data to a variable, finish 
redisplay, and then run the hook (if the data says so)?

> In addition, it will require us to record somewhere (probably, in the
> window object) the last used width for number display, so we could
> compare that with the new one.  This is not as simple as it sounds,
> because most redisplay cycles avoid redrawing the entire window, so
> determining just where in the code to perform this comparison is a
> non-trivial decision.

*resigned shrug*

> So I'd like to avoid this if possible.

It's somewhat hypothetical, but I'd like to refer to (*) above. That is, 
somebody will probably ask for that anyway, sooner or later.