Re: Issue 3330: redo much of the stencil stacking/spacing/empty-check (issue 8869044)

[David Kastrup]

"Keith OHara" <address@hidden> writes:

> On Sun, 05 May 2013 01:20:17 -0700, <address@hidden> wrote:
>
>> Maintaining a "cursor position" in stack-stencil-line and friends means
>> that you can't assemble partial lines yourself in a manner blending in.
>> That's bad.
>
> Oh. I thought it was good.  If the possibly-backspaced cursor is
> forgotten when \line is finished, then the user doesn't have to
> remember where the cursor ended up.

Why would he backspace when he doesn't mean it?

> \markup { A
>  \line {reverse turn \hspace#-5 \raise #2 \musicglyph #"scripts.reverseturn" }
>  is found in the original manuscript.}
>
> I suppose this comes out the same in your more-recent iterations.
> Only backspace at the end of a \line has a difference.  Even in that
> case I would rather forget about pending backspaces.

Which would mean that it would become impossible to assemble lines from
partial lines.

> The original fix to the issue suffered because a parenthesized item
> (with repaired refpoint) blended in when we assembled partial lines
> parenFlat = \markup {\hspace#-2 ( \flat )} \markup {An editorial
> \parenFlat flat} It is a little surprising if \parenFlat carries a
> pending backspace. If the markup building \parenFlat implements the
> backspace, and then tells no-one about it, it makes a simpler
> interface.

You should take a look at the regtest differences of this issue.  It
fixes several alignment problems with parenthesized items which are now
positioned according to their content reference point rather than the
start of the opening paren.

In a similar vein, it fixes the positioning of horizontal brackets,
making the bracket contents line up with the rest of the line rather
than using the lower bracket as a baseline.

> It looks very good that you made 'empty' mean (+inf . inf) so that
> negative extents don't count as empty.  But then defining 'half-empty'
> complicates things again, and I have not found a use for it.

Uh, reality check?  It fixes the hspace/concat bug you encountered
elsewhere in a clean manner, it lets page numbers in table of contents
actually appear flush to the right (like the page number in the page
headings does), it makes \hspace add a predictable amount of space, it
makes indentations at the start of auto-filled paragraphs remain rigid
rather than being expanded along with other spaces...

It might make sense to introduce another primitive instead of
combine-at-edge, like ly:stack-stencils or similar for the operation of
stacking stencils.  But at any rate, I don't see that there is a
reasonable substitute to creating a coherent and dependable operation
for this.  It is easy to see that all the variety of different
hard-coded stencil stacking operations have lead to blooming
inconsistency in the behavior of basic LilyPond markup commands.  In
response to bug reports, various commands get various, partly
conflicting fixes, and the game repeats.

I want to get this over with.

-- 
David Kastrup