> 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 sim
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) visib
>> (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 c
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-
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 hidde
LGTM.
https://codereview.appspot.com/319870043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
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
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 kno
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 = {
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
forceExtend
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
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-exten
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
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
>>> 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
>>> 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 trialbui
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-th
18 matches
Mail list logo