Introduce new markup-command draw-squiggle-line.

Introduce new markup-command draw-squiggle-line.

Change regtest /input/regression/markup-line-styles.ly accordingly

[thomasmorley651, 2016-01-05 15:28:48]

Please review

[pkx166h, 2016-01-05 18:18:54]

Fails make doc.

https://codereview.appspot.com/281210043/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/281210043/diff/1/scm/define-markup-commands.sc...
scm/define-markup-commands.scm:326: @code{angularity], @code{height} and
@code{orientation}
oops! 
@code{angularity} not @code{angularity]

This breaks make doc.

[thomasmorley651, 2016-01-05 20:29:37]

corrects typo in doc-string

[thomasmorley651, 2016-01-05 20:30:56]

https://codereview.appspot.com/281210043/diff/1/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/281210043/diff/1/scm/define-markup-commands.sc...
scm/define-markup-commands.scm:326: @code{angularity], @code{height} and
@code{orientation}
On 2016/01/05 18:18:54, pkx166h wrote:
> oops! 
> @code{angularity} not @code{angularity]
> 
> This breaks make doc.
> 

Sorry. Done.

[thomasmorley651, 2016-01-06 11:59:48]

improve coding, better regtest

[pkx166h, 2016-01-06 13:35:15]

Don't forget this will (eventually) also need

1. An entry in Changes.tely (preferably with an example)
2. An entry in the appropriate NR location Appendix (if that is the right
place).

[simon.albrecht, 2016-01-06 18:34:09]

On 2016/01/06 13:35:15, pkx166h wrote:
> Don't forget this will (eventually) also need
> 
> 1. An entry in Changes.tely (preferably with an example)
> 2. An entry in the appropriate NR location Appendix (if that is the right
> place).

The NR A10 entry is auto-generated, I think.

[simon.albrecht, 2016-01-06 19:13:58]

This makes for a nice addition. The interface could be improved, though.
Best, Simon

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
scm/define-markup-commands.scm:309: (define-markup-command (draw-squiggle-line
layout props sq-length dest eq-end?)
For the third parameter, ‘sq-number-odd?’ might be a more descriptive name IMO.

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
scm/define-markup-commands.scm:314: (height 0.5)
How about using `(height-fraction 1)`, with `(define height (* sq-length
height-fraction))`? That would be more descriptive of the looks. Also it seems
to me that the results are good only for height-fraction >= 1.

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
scm/define-markup-commands.scm:325: It's appearance may be customized by
overrides for @code{thickness},
s/It's/Its/

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
scm/define-markup-commands.scm:326: @code{angularity}, @code{height} and
@code{orientation}
(full stop or colon missing)

[thomasmorley651, 2016-01-07 00:04:26]

Too late for a follow-up, but:

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
scm/define-markup-commands.scm:309: (define-markup-command (draw-squiggle-line
layout props sq-length dest eq-end?)
On 2016/01/06 19:13:58, simon.albrecht wrote:
> For the third parameter, ‘sq-number-odd?’ might be a more descriptive name
IMO.

The main motivation to name it "eq-end?" was to keep the
80-characters-line-width. For now I let it as is. 
Not sure ‘sq-number-odd?’ is really more descriptive.
Others?

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
scm/define-markup-commands.scm:314: (height 0.5)
On 2016/01/06 19:13:58, simon.albrecht wrote:
> How about using `(height-fraction 1)`, with `(define height (* sq-length
> height-fraction))`? That would be more descriptive of the looks. 

There are two general, sometimes conflicting problems here:
(1)
Which arguments should hold a default-value and then should be coded as
properties?
(2)
Which properties can be used at all?

I would have loved to make "eq-end?" above a property with a boolean
default-value. But I vaguely remember David K explained the inflationary use of
new properties will probably cause problems (cc-ing him). This would be true for
`height-fraction' as well.
I tried to give the other properties default-values which will be nice for the
most common use-cases.
But for not so common line-lengths, they will not return good output.
How to deal with it? 
I could sort of reset/adjust the user-input. But I'm already not very happy
scaling the user input of `sq-length' to fit the final line-length. (No way to
do this different, though.)
The other way is to let it up to the user (wanting unusual values), to figure
them out himself. I think we should go this route, at least it respects the
user-input.

> Also it seems
> to me that the results are good only for height-fraction >= 1.

Why should `height' be influenced by `sq-length' in any way?
As stated above the user is responsible to find the needed values.

Look at this example, with high zoom:

#(set-global-staff-size 500) %%!!!
\markup {
  \override #'(thickness . 0.04) 
  \override #'(height . 0.03)
  \draw-squiggle-line #0.01 #'(0.2 . 0) ##t
}

It will return good output and still all values are adjustable.
`height-fraction' would be a multiplyer (with value 3 in this case)
Consequently we could do `thickness-fraction' (with value 4 here) as well.
I think everyone will agree that would be a bad idea. `thickness' needs to be
given as absolute value (although scaled by `line-thickness', which is
discussable, but inline with many other markup-commands). Why do it different
for `height'?

Or this one:
\markup {
  \override #'(thickness . 0.05) 
  \override #'(height . 0.25)
  \draw-squiggle-line #0.5 #'(5 . 0) ##t
}

`height-fraction' would be 0.5 and I see no problem here, _if_ thickness is
adjusted as well.

[thomasmorley651, 2016-01-07 21:20:16]

corrects doc-string, adds entry in changes

[thomasmorley651, 2016-01-07 21:21:09]

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
scm/define-markup-commands.scm:314: (height 0.5)
On 2016/01/07 00:04:26, thomasmorley651 wrote:
> On 2016/01/06 19:13:58, simon.albrecht wrote:
> > How about using `(height-fraction 1)`, with `(define height (* sq-length
> > height-fraction))`? That would be more descriptive of the looks. 
> 
> There are two general, sometimes conflicting problems here:
> (1)
> Which arguments should hold a default-value and then should be coded as
> properties?
> (2)
> Which properties can be used at all?
> 
> I would have loved to make "eq-end?" above a property with a boolean
> default-value. But I vaguely remember David K explained the inflationary use
of
> new properties will probably cause problems (cc-ing him). This would be true
for
> `height-fraction' as well.
> I tried to give the other properties default-values which will be nice for the
> most common use-cases.
> But for not so common line-lengths, they will not return good output.
> How to deal with it? 
> I could sort of reset/adjust the user-input. But I'm already not very happy
> scaling the user input of `sq-length' to fit the final line-length. (No way to
> do this different, though.)
> The other way is to let it up to the user (wanting unusual values), to figure
> them out himself. I think we should go this route, at least it respects the
> user-input.
> 
> > Also it seems
> > to me that the results are good only for height-fraction >= 1.
> 
> Why should `height' be influenced by `sq-length' in any way?
> As stated above the user is responsible to find the needed values.
> 
> Look at this example, with high zoom:
> 
> #(set-global-staff-size 500) %%!!!
> \markup {
>   \override #'(thickness . 0.04) 
>   \override #'(height . 0.03)
>   \draw-squiggle-line #0.01 #'(0.2 . 0) ##t
> }
> 
> It will return good output and still all values are adjustable.
> `height-fraction' would be a multiplyer (with value 3 in this case)
> Consequently we could do `thickness-fraction' (with value 4 here) as well.
> I think everyone will agree that would be a bad idea. `thickness' needs to be
> given as absolute value (although scaled by `line-thickness', which is
> discussable, but inline with many other markup-commands). Why do it different
> for `height'?
> 
> Or this one:
> \markup {
>   \override #'(thickness . 0.05) 
>   \override #'(height . 0.25)
>   \draw-squiggle-line #0.5 #'(5 . 0) ##t
> }
> 
> `height-fraction' would be 0.5 and I see no problem here, _if_ thickness is
> adjusted as well.

So, I strongly object here to change the user-interface to something other than
the usage of absolute values and not doing any further adjustments. I think it
wouldn't help, but obfuscate what's going on.

Otoh, I see this different for markup-commands which do sort of wrapping
themselves around an argument, like \circle or \parenthesize.
Here I wouldn't object to do adjustments and use multiplayer and the like.
because the user most likely want the _argument_ circled, parenthesized, etc in
a nice mannor, out of the box, without need to fight with properties most of the
time.
(I do have an improved parenthesize-markup-command lieing around locally, only
needing some final polish, where I do exactly this sort of coding)

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
scm/define-markup-commands.scm:325: It's appearance may be customized by
overrides for @code{thickness},
On 2016/01/06 19:13:58, simon.albrecht wrote:
> s/It's/Its/

Done.

https://codereview.appspot.com/281210043/diff/40001/scm/define-markup-command...
scm/define-markup-commands.scm:326: @code{angularity}, @code{height} and
@code{orientation}
On 2016/01/06 19:13:58, simon.albrecht wrote:
> (full stop or colon missing)

Done.

[thomasmorley651, 2016-01-07 21:22:13]

On 2016/01/06 13:35:15, pkx166h wrote:
> Don't forget this will (eventually) also need
> 
> 1. An entry in Changes.tely (preferably with an example)

Done.

> 2. An entry in the appropriate NR location Appendix (if that is the right
> place).

As Simon already pointed out this will be generate automatically.