Re: music function to be included somewhere in scm/*

[Werner LEMBERG]

> How about "collapse-length", which would be analogous to
> "collapse-height"?  This exists already and means "Minimum height of
> system start delimiter.  If equal or smaller, the bracket/brace/line
> is removed."

Thanks for finding this property name!  I vote for it because of the
striking similarity of usage.  Note, however, that it would need a
small change to the code so that we really have `equal or smaller'.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Trevor Daniels]

Noeck wrote Friday, December 16, 2016 9:08 PM

> Am 16.12.2016 um 17:38 schrieb Alexander Kobel:
>> [2] Side Note: other proposed names for minimum-length so far:
>> 
>> (1) minimum-space
>> (2) show-length
>> (3) hide-below-length
>> (4) hide-if-shorter-than
>> (5) minimum-visibility
>> (6) visibility-threshold
>> (7) printing-threshold
>> (8) extender-threshold
> 
> At a first glance, the property is still the same, just the behaviour
> for shorter extenders changed:
> 
> before: shorter extenders are prolonged
> after:  shorter extenders are not visible
> 
> But at a second glance, the minimum-length for LilyPond grobs usually
> means that the object is visible and the length is at least
> minimum-length (for glissandi, etc.). Using it to hide a shorter object
> feels inconsistent, IMHO. So I agree with Werner. But I have no
> favourite naming, all of them sound wrong to me - a slight preference
> for (6).

Definitely not "minimum-length" which means "Try to make a spanner at
least this long." 

How about "collapse-length", which would be analogous to "collapse-height"?
This exists already and means "Minimum height of system start delimiter. 
If equal or smaller, the bracket/brace/line is removed."

"remove-threshold" is another possibility.

Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Werner LEMBERG]

>> (1) minimum-space
>> (2) show-length
>> (3) hide-below-length
>> (4) hide-if-shorter-than
>> (5) minimum-visibility
>> (6) visibility-threshold
>> (7) printing-threshold
>> (8) extender-threshold
> 
> At a first glance, the property is still the same, just the
> behaviour for shorter extenders changed:
> 
> before: shorter extenders are prolonged
> after:  shorter extenders are not visible
> 
> But at a second glance, the minimum-length for LilyPond grobs
> usually means that the object is visible and the length is at least
> minimum-length (for glissandi, etc.).  Using it to hide a shorter
> object feels inconsistent, IMHO.  So I agree with Werner.  But I
> have no favourite naming, all of them sound wrong to me - a slight
> preference for (6).

What about `length-threshold'?


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Noeck]

Am 16.12.2016 um 17:38 schrieb Alexander Kobel:
> [2] Side Note: other proposed names for minimum-length so far:
> 
> (1) minimum-space
> (2) show-length
> (3) hide-below-length
> (4) hide-if-shorter-than
> (5) minimum-visibility
> (6) visibility-threshold
> (7) printing-threshold
> (8) extender-threshold

At a first glance, the property is still the same, just the behaviour
for shorter extenders changed:

before: shorter extenders are prolonged
after:  shorter extenders are not visible

But at a second glance, the minimum-length for LilyPond grobs usually
means that the object is visible and the length is at least
minimum-length (for glissandi, etc.). Using it to hide a shorter object
feels inconsistent, IMHO. So I agree with Werner. But I have no
favourite naming, all of them sound wrong to me - a slight preference
for (6).

Cheers,
Joram

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Knut Petersen]

Hi Paul, Alexander et. al!

I need to be very short as a rehearsal is waiting.

I'd advocate to keep minimum-length.
I also need some way to force an extender and to inhibit extender generation.
Forcing an individual extender should overrule a general inhibition of 
extenders.
Details can be hidden by some music functions ... but there's not time to 
generate
a patch now.

Have a look at the attached ly and the generated pdf ... and comment on the
chosen names and syntax. It should be self-explanatory.

cu,
 Knut

\version "2.19.53"

\paper {
  #(set-paper-size "a4")
  ragged-right = ##f 
  left-margin = 1\cm
  line-width = 19\cm
  top-margin = 1\cm
  bottom-margin = 1\cm
  ragged-bottom = ##f
  ragged-last-bottom = ##f
}

\pointAndClickOff

#(set-global-staff-size 16)

\markup { "automatic extenders, minimum-length 7 "} 
<<
{ c''1 2 ~ 2 2 4 ~ 4 4 8 ~ 8 8  16 ~ 16 4 1  \bar "|." }
\addlyrics { \noExtenderLimit #7  \repeat unfold 5 {  foo -- bar }}
>>

\markup { "automatic extenders, minimum-length 3.5 "} 
<<
{ c''1 2 ~ 2 2 4 ~ 4 4 8 ~ 8 8  16 ~ 16 4 1  \bar "|." }
\addlyrics { \noExtenderLimit #3.5 \repeat unfold 5 {  foo -- bar }}
>>

\markup { "automatic extenders, minimum-length 1 "} 
<<
{ c''1 2 ~ 2 2 4 ~ 4 4 8 ~ 8 8  16 ~ 16 4 1  \bar "|." }
\addlyrics { \noExtenderLimit #1 \repeat unfold 5 {  foo -- bar }}
>>

\markup { "automatic extenders, mixed manual and automatic melismata, extender on last note forced to length 5"} 
<<
{ \autoBeamOff c''2 2 4\( 4 4 4\) 4 4 4\( 4( 4) 8[ 8] 8\) 16\(\melisma 16\melismaEnd 4\) 1 \bar "|." }
\addlyrics { \noExtenderLimit #8 foo -- _ bar _ _ _ foo -- _ bar _ _ _  foo -- _ \forceExtenderTo #5 bar }
>>

\markup { "automatic extenders, mixed manual and automatic melismata, first extender shortened, extender on last note forced "} 
<<
{ \autoBeamOff c''2 2 4\( 4 4 4\) 4 4 4\( 4( 4) 8[ 8] 8\) 16\(\melisma 16\melismaEnd 4\) 1 \bar "|." }
\addlyrics { \noExtenderLimit #8
foo -- _ \forceExtender bar _ "" _  foo -- _ bar _ _ _  foo -- _ \forceExtender bar _ _ _ }
>>

\markup { "Issue 1006 revisited, last extender forced and tweaked to the left, minimum-length 2 "} 
\score { 
  <<
\new Staff \relative c'' { 
  \time 2/1
  \repeat volta 2 {
r4 g4 d'2. a4 bes2~
bes  a2 g1~
  }
  \alternative{
   { g2 fis4 e fis1 d'1 c2 bes}
   { g\repeatTie fis4 e fis1 }
  }
  \bar "|."
}
\addlyrics {
   \noExtenderLimit #2
of Prin -- ces all _ _ the _ flow’r. Who took a-
   \earlyExtender #-4 the _ flow’r.
}
  >>
}

\markup { "Issue 1006 revisited, last extender forced and tweaked to the left, minimum-length 1 "} 
\score { 
  <<
\new Staff \relative c'' { 
  \time 2/1
  \repeat volta 2 {
r4 g4 d'2. a4 bes2~
bes  a2 g1~
  }
  \alternative{
   { g2 fis4 e fis1 d'1 c2 bes}
   { g\repeatTie fis4 e fis1 }
  }
  \bar "|."
}
\addlyrics {
   \noExtenderLimit #1
of Prin -- ces all _ _ the _ flow’r. Who took a-
   \earlyExtender #-4  the _ flow’r.
}
  >>
}

\markup{Here our melisma detection fails. We need to override. }
\score {
  <<
\new Voice = "singleVoice" {
\relative {
	  a'4 a a a
	  \repeat volta 3 { b4 b b b }
  c4 c c c
	   }
}
\new Lyrics \lyricsto "singleVoice" {
  Not re -- peat -- ed.
  <<
{ The first time words.	}
\new Lyrics { \set associatedVoice = "singleVoice"  Sec -- ond time \noExtender words. }
\new Lyrics { \set associatedVoice = "singleVoice"  The third time \noExtender words. }
  >>
  The end sec -- tion.
}
  >>
}

\markup {There should be no extender from volta 1 to volta 2 but a short extender starting at volta 2}
\score {
  <<
\new Staff {
  \time 2/4
  \new Voice = "melody" {
\relative {
  \set melismaBusyProperties = #'()
  \repeat volta 2 { b'4 b ~}
  \alternative { { b b } { b \repeatTie c } }
  \unset melismaBusyProperties
  c4 c
}
  }
}
\new Lyrics {
  \lyricsto "melody" {
\repeat volta 2 { Here's a __ }
\alternative {
  { \skip 1 verse }
  { \earlyExtender #-4  sec -- }
}
ond one.
  }
}
  >>
}

\markup {Best solution to that problem ...}
\score {
  <<
\new Staff {
  \time 2/4
  \new Voice = "melody" {
\relative {
  \repeat volta 2 { b'4 b ~}
  \alternative { { b b } { b \repeatTie c } }
  c4 c
}
  }
}
\new Lyrics {
  \lyricsto "melody" {
Here's a verse. "" ""
  }
}
\new Lyrics {
  \lyricsto "melody" {
  Here's \shortenExtender#6 one "" \earlyExtender #-6  more to sing.
  }
}
  >>
}

\layout {
}


lyrextest.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list

Fix scripts for environments where "set -ux" carries over (issue 319870043 by truer...@gmail.com)

[lemzwerg]

LGTM.

https://codereview.appspot.com/319870043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Alexander Kobel]

Hi Paul.

On 2016-12-16 16:02, Paul wrote:

Hi Knut and everyone,

Great to see your work which seems like a nice improvement.  I just have
some thoughts on the implementation / use of properties.

We are just talking about grob properties and not context properties
right?  In that case no need to also create context properties as you do
in your patch, since the grob properties are sufficient.


Yes, I think that's a general agreement now. AFAICS, the idea of context 
properties quickly vanished after we recognized that we can get rid of 
__ (or ExtenderEvents) entirely, at least as far as the user is 
concerned. They are now more like an implementation detail for no-extender.



What about a way to do this with fewer than 3 separate grob properties?

LyricExtender.minimum-length
LyricExtender.no-extender
LyricExtender.force-extender

If I understand correctly, only 1 of 3 kinds of behavior can be in
effect at a given point:

1. no extensions
2. forced extensions
3. automatically added extension depending on a 'minimum-length' number


Not quite. I can imagine that no-extender and force-extender could be 
combined. E.g., as create-extender = { one of #'auto, #'never, #'always }:


#'auto means the default: create extenders on melismata and nowhere else.
#'never means: create no extenders, period.
#'always means that extenders are enforced even on non-melismata (where, 
by definition, there should not be an extender; but there are situations 
where it makes sense to overwrite it; e.g., for a continuation of an 
extender in a second volta repeat, or in divisi lyrics).


Minimum-length [2] is orthogonal - it is more concerned with the layout. 
With some reasonable minimum-length, extenders that reduce to mere 
flyspecks are hidden. This happens often in somewhat dense choral 
settings: the extender is not printed if the syllable text is almost as 
wide (or even wider) than the distance between the respective noteheads. 
It's a threshold value that tells which existing extenders will be 
printed and visible. [1]
But this decision entirely depends on horizontal spacing, and will vary 
with line breaks, other voices, etc. IMHO, that's a whole different 
quality of a variable than the previous one (existence vs. appearance). 
And the general design principle throughout Lilypond is to separate 
semantics from layout as much as possible.


[1] One exception: on forced extenders on non-melismata (which do not 
have any natural length, obviously), minimum-length will not serve as a 
threshold, but to /set/ the length.


[2] Side Note: other proposed names for minimum-length so far:

(1) minimum-space
(2) show-length
(3) hide-below-length
(4) hide-if-shorter-than
(5) minimum-visibility
(6) visibility-threshold
(7) printing-threshold
(8) extender-threshold



So why not one grob property (name to be determined) that can be a
boolean or a number:

LyricExtender.extenders = ##f   % no extensions
LyricExtender.extenders = ##t   % forced extensions
LyricExtender.extenders = 2% a number, auto extensions

For example, it could be set to a number and then use \once to set it to
##t to force (or ##f to suppress) a given extender.


See [1] above; we need to be able to specify a length for forced 
extenders (that do not have a natural length because there's only one 
note). Yes, something like extenders = #'(forced? length) with a boolean 
for forced? and a number for length would be sufficient (note that #'(#f 
+inf.0) amounts to #'never...), but that's quite opaque.



Another possibility (2 properties) might be:

LyricExtender.stencil = ##f% no extensions
LyricExtender.force-extender = ##t  % forced extensions
LyricExtender.minimum-length = 2% auto extensions (if force-extender
is not ##t and stencil is not ##f)


Yes, that'll work: stencil = ##f means #'never; stencil = ##t and 
force-extender = ##t means #'always; and stencil = ##t and 
force-extender = ##f means #'auto.
However, I personally dislike to touch stencil. That's my last resort, 
but it feels hacky; IMHO stencil is a more or less internal layout 
procedure, and I should not have to abuse it for semantic purposes 
(i.e., #'never).



Cheers,
Alexander

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Paul]

Hi Knut and everyone,

Great to see your work which seems like a nice improvement.  I just have 
some thoughts on the implementation / use of properties.


We are just talking about grob properties and not context properties 
right?  In that case no need to also create context properties as you do 
in your patch, since the grob properties are sufficient.


What about a way to do this with fewer than 3 separate grob properties?

LyricExtender.minimum-length
LyricExtender.no-extender
LyricExtender.force-extender

If I understand correctly, only 1 of 3 kinds of behavior can be in 
effect at a given point:


1. no extensions
2. forced extensions
3. automatically added extension depending on a 'minimum-length' number

So why not one grob property (name to be determined) that can be a 
boolean or a number:


LyricExtender.extenders = ##f   % no extensions
LyricExtender.extenders = ##t   % forced extensions
LyricExtender.extenders = 2% a number, auto extensions

For example, it could be set to a number and then use \once to set it to 
##t to force (or ##f to suppress) a given extender.



Another possibility (2 properties) might be:

LyricExtender.stencil = ##f% no extensions
LyricExtender.force-extender = ##t  % forced extensions
LyricExtender.minimum-length = 2% auto extensions (if force-extender 
is not ##t and stencil is not ##f)



Am I missing something?  What do you think?

Cheers,
-Paul


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Alexander Kobel]

On 2016-12-16 15:20, Urs Liska wrote:

Am 16. Dezember 2016 15:11:59 MEZ, schrieb David Nalesnik 
:

On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen [...]

(define-public (forceExtender)
  (once (overrideProperty '(LyricExtender force-extender) #t)))

into scm/music-functions.scm, lilypond does know \forceExtender ...
but it complains about a "non-music expression" if it is used ...


Ah, this one. You explicitly have to create a music function. Maybe

https://scheme-book.ursliska.de/scheme/music-function-primer.html

helps you?


Oh, that looks nice... I need to spend some time on that one.


But you can say

(define forceExtender (define-musi-function ...


(define forceExtender
 (define-music-function () ()
  (once (overrideProperty '(LyricExtender force-extender) #t

should work, yes. But I think David's suggestion is even easier and 
recommended. Note that

  fgrep define-music-function scm/*
gives a pretty short list of 4 hits, and 2 of which are in the 
definition of define-music-function itself. And

  fgrep define-music-function ly/* | wc -l
shows a count of 131...


If you are defining a music function, do it in
ly/music-functions-init.ly,


In a .ly file (which is processed with all the syntactic sugar that 
Lilypond has to offer) you can simply write

  forceExtender = \once \override LyricExtender.force-extender = ##t
and that's it.
By the way, for the sake of consistency with other commands (except, 
maybe, \hideNotes and \unHideNotes): My preferred choice of names would be

  forcedExtendersOn  = \override LyricExtender.force-extender = ##t
  forcedExtendersOff = \override LyricExtender.force-extender = ##f
and a user can prefix a \once if necessary. (Unless someone comes up 
with an apt antonym of "force" here - free, release, permit don't sound 
sound...)



Cheers,
Alexander

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[David Nalesnik]

On Fri, Dec 16, 2016 at 8:11 AM, David Nalesnik
 wrote:
> On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen
>  wrote:
>> Am 16.12.2016 um 14:38 schrieb Urs Liska:
>>>
>>>
 As your knowledge of scheme seems to be well developed, could you give
 a scheme equivalent of

 forceExtender = { \once  \override LyricExtender.force-extender = ##t }

 that is acceptable to lilypond?
>>>
>>> #(once (overrideProperty '(LyricExtender force-extender) #t))
>>>
>>> (untested)
>>
>> Thanks a lot for the quick answer. If I put
>>
>> (define-public (forceExtender)
>>   (once (overrideProperty '(LyricExtender force-extender) #t)))
>>
>> into scm/music-functions.scm, lilypond does know \forceExtender ... but it
>> complains about a "non-music expression"
>> if it is used ...
>
>
> If you are defining a music function, do it in ly/music-functions-init.ly,

Or if it's simply setting a property, as here, in ly/property.init.ly ...

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Urs Liska]

Am 16. Dezember 2016 15:11:59 MEZ, schrieb David Nalesnik 
:
>On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen
> wrote:
>> Am 16.12.2016 um 14:38 schrieb Urs Liska:
>>>
>>>
 As your knowledge of scheme seems to be well developed, could you
>give
 a scheme equivalent of

 forceExtender = { \once  \override LyricExtender.force-extender =
>##t }

 that is acceptable to lilypond?
>>>
>>> #(once (overrideProperty '(LyricExtender force-extender) #t))
>>>
>>> (untested)
>>
>> Thanks a lot for the quick answer. If I put
>>
>> (define-public (forceExtender)
>>   (once (overrideProperty '(LyricExtender force-extender) #t)))
>>
>> into scm/music-functions.scm, lilypond does know \forceExtender ...
>but it
>> complains about a "non-music expression"
>> if it is used ...


Ah, this one. You explicitly have to create a music function. Maybe

https://scheme-book.ursliska.de/scheme/music-function-primer.html

helps you?

But you can say

(define forceExtender
  (define-musi-function ...

HTH
Urs

>
>
>If you are defining a music function, do it in
>ly/music-functions-init.ly,

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[David Nalesnik]

On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen
 wrote:
> Am 16.12.2016 um 14:38 schrieb Urs Liska:
>>
>>
>>> As your knowledge of scheme seems to be well developed, could you give
>>> a scheme equivalent of
>>>
>>> forceExtender = { \once  \override LyricExtender.force-extender = ##t }
>>>
>>> that is acceptable to lilypond?
>>
>> #(once (overrideProperty '(LyricExtender force-extender) #t))
>>
>> (untested)
>
> Thanks a lot for the quick answer. If I put
>
> (define-public (forceExtender)
>   (once (overrideProperty '(LyricExtender force-extender) #t)))
>
> into scm/music-functions.scm, lilypond does know \forceExtender ... but it
> complains about a "non-music expression"
> if it is used ...


If you are defining a music function, do it in ly/music-functions-init.ly,

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Knut Petersen]

Am 16.12.2016 um 14:38 schrieb Urs Liska:



As your knowledge of scheme seems to be well developed, could you give
a scheme equivalent of

forceExtender = { \once  \override LyricExtender.force-extender = ##t }

that is acceptable to lilypond?

#(once (overrideProperty '(LyricExtender force-extender) #t))

(untested)

Thanks a lot for the quick answer. If I put

(define-public (forceExtender)
  (once (overrideProperty '(LyricExtender force-extender) #t)))

into scm/music-functions.scm, lilypond does know \forceExtender ... but it complains 
about a "non-music expression"
if it is used ...

Cheers,
 Knut



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Urs Liska]

Am 16. Dezember 2016 14:31:43 MEZ, schrieb Knut Petersen 
:
>Hi Alexander et. al.!
>
>For me scheme still is the most counterintuitive way to program a
>computer. I believe that I discovered a
>thousand ways to trigger the message  "[...] warning: Ignoring
>non-music expression". Could we switch
>to something easy like postscript or x86 assembly? ;-))
>
>As your knowledge of scheme seems to be well developed, could you give
>a scheme equivalent of
>
>forceExtender = { \once  \override LyricExtender.force-extender = ##t }
>
>that is acceptable to lilypond?

#(once (overrideProperty '(LyricExtender force-extender) #t))

(untested)

HTH
Urs 

>
>cu,
>  Knut

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Knut Petersen]

Hi Alexander et. al.!

For me scheme still is the most counterintuitive way to program a computer. I 
believe that I discovered a
thousand ways to trigger the message  "[...] warning: Ignoring non-music 
expression". Could we switch
to something easy like postscript or x86 assembly? ;-))

As your knowledge of scheme seems to be well developed, could you give a scheme 
equivalent of

forceExtender = { \once  \override LyricExtender.force-extender = ##t }

that is acceptable to lilypond?

cu,
 Knut

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: linux-ppc harfbuzz GUB build error

[Masamichi Hosoda]

>>> In my environments, autoconf does not raise such error.
>>> Do you set the "set -u" or "set -o nounset" somewhere?
>>> If so, would you remove the setting?
>> The set -u (or to be complete set -ux) I discovered inside
>> 
>> /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/smart-configure.sh
>> 
>> which was the command that was called when the error was signalled
> 
> I've noticed that smart-autogen.sh has "set -ux" and it is invoked from GUB.
> If I understand correctly, "set -u" and "set -x" etc. do not carry over
> into child processes.
> 
> However, at least in your log file,
> "set -x" seems to be carried over to the child process.
> From smart-autogen.sh through autogen.sh to autoconf,
> all scripts are setted trace mode.
> 
[...snip...]
> 
> Perhaps, also "set -u" is carried over in your environment
> and it is not carried over in my environment.
> 
> I have no idea.
> But, in CentOS, /bin/sh is symbolic link to bash,
> whereas in Ubuntu, /bin/sh is dash.
> I think that this difference is influenced.

Anyway, I've noticed that if the environment variable SHELLOPTS exists,
"set -ux" and "set -e" carry over to the child processes.
There may be other conditions that it carries over.

In order to avoid this issue,
there is a way to "set +ux" before invoking the child process.
So I've created a patch for LilyPond's smart-autogen.sh and smart-configure.sh.

https://sourceforge.net/p/testlilyissues/issues/5013/
https://codereview.appspot.com/319870043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: linux-ppc harfbuzz GUB build error

[Masamichi Hosoda]

>>> Maybe the issue is to use ICU of CentOS system.
>>> 
>>> I've created a patch.
>>> https://github.com/trueroad/gub/commit/081cc91f698186795dca45e8d6db8af6616826d4
>>> 
>>> If this patch solves the issue, I will send the pull request.
>> 
>> New gub bootstrapped from you repo; running a trialbuild tonight… more to 
>> follow tomorrow
>> 
> New build from Masamichi’s branch passed the linux ppc harfbuzz, so the ICU 
> patch worked. Now looking into a breaking freebsd-x86 lilypond error: 

I've created the harfbuzz ICU pull request.
https://github.com/gperciva/gub/pull/33

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Simon Albrecht]

On 16.12.2016 08:30, Marc Hohl wrote:

Am 16.12.2016 um 02:09 schrieb Alexander Kobel:

Hi all.

[...]

What about hide-below-length or hide-if-shorter-than?


minimum-visibility?


We’re getting closer… I think ‘threshold’ describes the functionality 
well; maybe visibility-threshold? printing-threshold? extender-threshold?


Best, Simon

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel