bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages

[martin rudalics <rudalics@gmx.at>]

 >> I miss you here.  Emacs now by default also extends the region to the
 >> right window edge.
 >
 > Emacs doesn't extend the region to the right window edge when the region
 > face was already customized, and has no "extend t" in the init file.

But when the region face was already customized we hardly talk about
the default any more.

 >> With Firefox these diffs are boxed in a subarea of the Firefox window.
 >> They do not start or extend at the window edges and text in these
 >> boxes is static, can neither overflow into a newline nor be broken.
 >
 > This is why I proposed to limit these boxes to some fixed column
 > like fill-column.

The point I wanted to make is that the diffs shown in that Firefox
window are static, you can't modify them.  Hence it's easy to produce
them with a once calculated, fixed column, even based on a variable
pitch font.  (Which, BTW, is an exaggeration - try to show that page
in the non-unified, side-by-side style, shrink the Firefox frame and
look at the barely readable mixture of line truncation and breaking.)

With Emacs, things are different.  When you ediff two buffers, you can
modify their contents any which way you want and any highlighting has
to adapt accordingly.  Thus any rectangular block concept based on a
previously established fixed column will break at least here.

 >> But I think that our (e)diff blocks are affected by the change and all
 >> their face settings probably have to change, as well as tables and
 >> listings.
 >
 > Yes, (e)diff face settings have to change, but actually I discovered
 > that diff-refined faces don't need to extend to the window edge,
 > because they don't form a block, they are word-based.

I wouldn't consider blocks, boxes or rectangles specially in the
present context.  None of these should, by design, automatically
extend to a window edge.  The fact that they did until Ergus pushed
his patch rather hints at a design shortcoming that, however,
installed itself in the minds of many users (including yours truly).

What we should consider specially IMHO are lines in certain, specific
environments like the above mentioned side-by-side windows used by
ediff for comparing two buffers.  There, having a highlight in one
window extend to the edge will ease passing to the corresponding line
in the other window (provided we can keep these lines in synch in the
first place - we'd urgently need code for that).

And in listings that may contain empty lines, indicating such a line
with a highlighting that expands to the edge it will probably make it
easier to re-focus a user's attention when scrolling that window.
Just as we do for 'hl-line' but without enabling it everywhere.

Still, most of these customization are merely a matter of taste and I
can't yet see the breakage I personally expected when a few weeks ago
I urged Ergus to install his patch ASAP.

martin