Fix underline-markup to make multiple calls have nice output

Fix underline-markup to make multiple calls have nice output

Amend regtest markup-commands.ly with an example for it.

[thomasmorley651, 2019-10-21 09:52:41]

Does this one need a convert-rule?

If so, I'd need some help. My python-skill is more or less zero.

[dak, 2019-10-21 10:31:32]

On 2019/10/21 09:52:41, thomasmorley651 wrote:
> Does this one need a convert-rule?
> 
> If so, I'd need some help. My python-skill is more or less zero.

I've just taken some look.  It would appear that the only other markup commands
using the "offset" property are the \tie/\overtie\undertie family.  Collision
avoidance would appear to make it somewhat desirable to let them share in the
scheme (in which case sticking with "offset" rather than "underline-offset"
would appear to make sense) but this would seem to make the "innermost has
largest offset" principle even weirder.

[thomasmorley651, 2019-10-21 11:02:12]

On 2019/10/21 10:31:32, dak wrote:
> On 2019/10/21 09:52:41, thomasmorley651 wrote:
> > Does this one need a convert-rule?
> > 
> > If so, I'd need some help. My python-skill is more or less zero.
> 
> I've just taken some look.  It would appear that the only other markup
commands
> using the "offset" property are the \tie/\overtie\undertie family.  Collision
> avoidance would appear to make it somewhat desirable to let them share in the
> scheme (in which case sticking with "offset" rather than "underline-offset"
> would appear to make sense) but this would seem to make the "innermost has
> largest offset" principle even weirder.

Well, there was no collision avoidance implemented for previous \underline and
\undertie, so the situation is not worse than before.

In the light of your findings we could even keep "offset" (saving the
convert-rule), imho. I don't think it gets much weirder than with
nested/overlapping \underlines anyway.

What do you think?

[dak, 2019-10-21 11:13:17]

On 2019/10/21 11:02:12, thomasmorley651 wrote:
> On 2019/10/21 10:31:32, dak wrote:
> > On 2019/10/21 09:52:41, thomasmorley651 wrote:
> > > Does this one need a convert-rule?
> > > 
> > > If so, I'd need some help. My python-skill is more or less zero.
> > 
> > I've just taken some look.  It would appear that the only other markup
> commands
> > using the "offset" property are the \tie/\overtie\undertie family. 
Collision
> > avoidance would appear to make it somewhat desirable to let them share in
the
> > scheme (in which case sticking with "offset" rather than "underline-offset"
> > would appear to make sense) but this would seem to make the "innermost has
> > largest offset" principle even weirder.
> 
> Well, there was no collision avoidance implemented for previous \underline and
> \undertie, so the situation is not worse than before.
> 
> In the light of your findings we could even keep "offset" (saving the
> convert-rule), imho. I don't think it gets much weirder than with
> nested/overlapping \underlines anyway.
> 
> What do you think?

The combination

    \markup \underline \overtie huh

would likely be madly confusing if the \underline managed to shift the \overtie
around.

[dak, 2019-10-21 11:20:03]

On 2019/10/21 11:13:17, dak wrote:
> On 2019/10/21 11:02:12, thomasmorley651 wrote:
> > On 2019/10/21 10:31:32, dak wrote:
> > > On 2019/10/21 09:52:41, thomasmorley651 wrote:
> > > > Does this one need a convert-rule?
> > > > 
> > > > If so, I'd need some help. My python-skill is more or less zero.
> > > 
> > > I've just taken some look.  It would appear that the only other markup
> > commands
> > > using the "offset" property are the \tie/\overtie\undertie family. 
> Collision
> > > avoidance would appear to make it somewhat desirable to let them share in
> the
> > > scheme (in which case sticking with "offset" rather than
"underline-offset"
> > > would appear to make sense) but this would seem to make the "innermost has
> > > largest offset" principle even weirder.
> > 
> > Well, there was no collision avoidance implemented for previous \underline
and
> > \undertie, so the situation is not worse than before.
> > 
> > In the light of your findings we could even keep "offset" (saving the
> > convert-rule), imho. I don't think it gets much weirder than with
> > nested/overlapping \underlines anyway.
> > 
> > What do you think?
> 
> The combination
> 
>     \markup \underline \overtie huh
> 
> would likely be madly confusing if the \underline managed to shift the
\overtie
> around.

So maybe \underline should retain the previous meaning and setting of offset and
add an _additional_ underline-shift defaulting to 0 for the sake of stacking? 
Then we'd not need a conversion rule at all, and the underline-shift would not
interact with over/undertie unless we wanted to.

[thomasmorley651, 2019-10-21 11:24:02]

On 2019/10/21 11:13:17, dak wrote:

> The combination
> 
>     \markup \underline \overtie huh
> 
> would likely be madly confusing if the \underline managed to shift the
\overtie
> around.

One could work around with
\markup 
  \underline \underline \underline \underline \underline
  \override #'(offset . 2) \overtie huh
Similiar to nested/overlapping underlines, if the user wants a different
stacking.

Stay with "underline-offset" then?

[thomasmorley651, 2019-10-21 11:26:06]

On 2019/10/21 11:24:02, thomasmorley651 wrote:
> On 2019/10/21 11:13:17, dak wrote:
> 
> > The combination
> > 
> >     \markup \underline \overtie huh
> > 
> > would likely be madly confusing if the \underline managed to shift the
> \overtie
> > around.
> 
> One could work around with
> \markup 
>   \underline \underline \underline \underline \underline
>   \override #'(offset . 2) \overtie huh
> Similiar to nested/overlapping underlines, if the user wants a different
> stacking.
> 

(Deleted by accident:)

I'm aware of the problem, though

> Stay with "underline-offset" then?

[thomasmorley651, 2019-10-21 15:36:04]

On 2019/10/21 11:20:03, dak wrote:
> > 
> > The combination
> > 
> >     \markup \underline \overtie huh
> > 
> > would likely be madly confusing if the \underline managed to shift the
> \overtie
> > around.
> 
> So maybe \underline should retain the previous meaning and setting of offset
and
> add an _additional_ underline-shift defaulting to 0 for the sake of stacking? 
> Then we'd not need a conversion rule at all, and the underline-shift would not
> interact with over/undertie unless we wanted to.

If I understand correctly, then old "offset" determined the gap between text-arg
and the underline. You suggest to keep this behaviour. I.e. for the gap between
the text-arg and _first_ underline.
And a new underline-shift, starting at 0, but modified by multiple calls of
\underline for stacking additional underlines.
Right?
Though, which value should we take for the gap between multiple lines, i.e.
which value to modify underline-shift?
I see two possibilities:
a) Use the one provided by "offset". This has some logic, sure, but an override
for it would affect the gap between original text-arg _and_ between multiple
additional underlines. As a user I'd want the possibility to set these two
differently.
Thus:
b) Introduce an additional property, determining the gap _between_ lines. Maybe
even called "underline-offset" or the like.

Then we would have the following properties
((thickness 1) (offset 2) (underline-shift 0) (underline-offset 2))

A user-override for underline-shift would disturb things, though. Maybe some
words in the doc-string about it?

[dak, 2019-10-21 15:51:33]

On 2019/10/21 15:36:04, thomasmorley651 wrote:

> Then we would have the following properties
> ((thickness 1) (offset 2) (underline-shift 0) (underline-offset 2))
> 
> A user-override for underline-shift would disturb things, though. Maybe some
> words in the doc-string about it?

Having both offset and underline-offset is confusing.  For spacing between equal
things we usually use distance, not offset (at least there is basic-distance or
was that baseline-skip ?).  So it would be thickness, offset, underline-shift,
underline-distance.  Or underline-skip ?  Probably the latter because it does
not include padding, thickness, etc.  Or should it?

Life is complicated.

[thomasmorley651, 2019-10-21 16:25:38]

Adress recent discussion