bug#29279: Sharing the margins

[Eli Zaretskii]

> Cc: 29279@debbugs.gnu.org, joostkremers@fastmail.fm
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 15 Nov 2017 16:23:01 +0200
> 
> On 11/15/17 5:42 AM, Eli Zaretskii wrote:
> 
> >> It might be just a matter of interpretation: even if all the padding is
> >> on the right, the "rightmost" column will remain such, among all the
> >> visible columns.
> > 
> > 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.

> > A stretch of white space between the
> > text and the margin display might not be what the package wants.
> 
> OK, can we think of a case where a package might want its margin content 
> to be _as far away_ from the text as possible? And become troubled if 
> some padding stands between it and the window edge?
> 
> 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.

> >> But the effects are almost entirely the same, aren't they? Both the
> >> change of margin width and the change of line numbers column width force
> >> the reflowing of buffer contents display.
> > 
> > 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.

> 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?

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.

So I'd like to avoid this if possible.