bug#28771: 26.0.60; A couple space display property feature requests

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: 28771@debbugs.gnu.org
> Date: Tue, 10 Oct 2017 15:27:03 -0600
> 
> To get an idea evaluate:
> (setq header-line-format
>       (concat (propertize " "
>                           'display
>                           '(space :align-to 0))
>               "test"))
> 
> The start of "test" is what I mean by the "left" of the "text-area".

Actually, my understanding is that 'left' is the number of pixels from
the left edge of the window to the start of "Test".  IOW, it's a pixel
width, not a position.  Right?

> For clarification, what you should see is 1 space before and 1 space
> after "Test", each the same pixel width as the left fringe.

Actually, by "space" you mean space displayed with 'highlight' face,
right?  Because there's a lot of "other" space in the header-line, but
you don't mean that space.  That's what tripped me originally.

> What should happen is that if you toggle the fringes/margins, then the
> spaces shrink and grow accordingly, with the exception of faulty
> scroll-bar width calculation. Using '(space :width left) does not have
> this faulty calculation.
> 
> The point is that the before/after stretch whitespace must have equal
> lengths at all times, regardless of fringe/margin/line-number/scroll-bar
> statuses.
> 
> > And again, this is limited to header-line, right?
> 
> I believe so (and the mode-line).

So what is the purpose of having the header-line or mode-line text
move relative to buffer text when some window decorations are
enabled/disabled or moved from left to right?  IOW, why did you need
the "space" on both sides of "Test" to be of the same pixel width,
independently of the scroll-bar position?  Right now, "Test" moves
together with buffer text, and so is always aligned with it, no matter
which side is the scroll bar on.  Why is that not TRT?

> >> 2. Suppose you want to align a string to the right edge of the window.
> >
> > What is "the right edge of the window" in this context?
> 
> The very ends of the window shown in the art in "(elisp) Window Sizes"
> (i.e., past RD).

Again, why do you need that?  Also, why cannot you use the existing
functions that return dimensions of the window and its decorations?

> > If you are talking only about header lines, maybe the solution (if we
> > need one) doesn't have to be such a general one.  Are there similar
> > problems with other lines in a window?
> 
> Maybe it doesn't, but since the general case is simple enough to
> implement, why not do it? I think it fits in with the existing code well
> enough.

It fits with the code, but not with the conceptual framework.  The
:align-to spec starts counting pixels at the left edge of the text
area, whereas with the new symbols you introduce it will start at a
different point.  That's confusing.

> Sorry, I should have been more clear -- appending/prepending a
> pixel-specified space string to an arbitrary string. Essentially a
> (concat <pixel-space> string <pixel-space>).

The only way to generate a stretch of whitespace is to use a 'space'
display spec.  So no, we don't have that.  The display engine cannot
display a glyph of a character with prepended or appended space,
because we ask the font back-end to produce the glyph metrics for us,
and those metrics come from the font.  That is why we must produce
stretch glyphs separately.