Re: Patch on dynamics and \RemoveEmptyStaves
On 3/26/20, James Lowe wrote: > Yes David K is correct. If someone could take a look at the scripts in > git-cl and get them working smoothly again (there are other errors > reported on this list about git-cl) it would be a boon to the dev team. By the way (this is not directly related but may orient how we decide to address git-cl’s future), do note that git-cl will apparently remain python2-only for the foreseeable future: https://github.com/rietveld-codereview/rietveld/issues/486 which will become more and more of a hindrance as python 2 gets phased out, and python 3, increasingly ubiquitous. V.
Re: Patch on dynamics and \RemoveEmptyStaves
On 26/03/2020 12:15, David Kastrup wrote:
Jean Abou Samra writes:
Hi,
Le 24/03/2020 à 23:05, Trevor a écrit :
Hi "Jean Abou Samra", you wrote
My SourceForge username is jean-abou-samra. Could someone please
give me write access to the issue tracker?
Added as a Developer, with Update and Create permissions in addition
to Read.
Welcome aboard!
Trevor
Thank you!
Here is a question about updating patches using git-cl: whenever I try
to upload the patch, I get this error.
IOError: ('http error', 401, 'Unauthorized', )
Traceback attached. What am I doing wrong?
The question is rather what git-cl is doing wrong. This is some fallout
from SourceForge changes (and/or our move from Google Code to there)
that nobody has gotten around to get fixed yet.
Yes David K is correct. If someone could take a look at the scripts in
git-cl and get them working smoothly again (there are other errors
reported on this list about git-cl) it would be a boon to the dev team.
James
Re: Patch on dynamics and \RemoveEmptyStaves
Jean Abou Samra writes:
> Hi,
>
> Le 24/03/2020 à 23:05, Trevor a écrit :
>
>> Hi "Jean Abou Samra", you wrote
>>> My SourceForge username is jean-abou-samra. Could someone please
>>> give me write access to the issue tracker?
>>
>> Added as a Developer, with Update and Create permissions in addition
>> to Read.
>>
>> Welcome aboard!
>>
>> Trevor
>
> Thank you!
>
> Here is a question about updating patches using git-cl: whenever I try
> to upload the patch, I get this error.
>
>
> IOError: ('http error', 401, 'Unauthorized', instance at 0x7f8715613370>)
>
>
> Traceback attached. What am I doing wrong?
The question is rather what git-cl is doing wrong. This is some fallout
from SourceForge changes (and/or our move from Google Code to there)
that nobody has gotten around to get fixed yet.
--
David Kastrup
Re: Patch on dynamics and \RemoveEmptyStaves
Hi,
Le 24/03/2020 à 23:05, Trevor a écrit :
Hi "Jean Abou Samra", you wrote
My SourceForge username is jean-abou-samra. Could someone please give
me write access to the issue tracker?
Added as a Developer, with Update and Create permissions in addition
to Read.
Welcome aboard!
Trevor
Thank you!
Here is a question about updating patches using git-cl: whenever I try
to upload the patch, I get this error.
IOError: ('http error', 401, 'Unauthorized', instance at 0x7f8715613370>)
Traceback attached. What am I doing wrong?
Best,
Jean Abou Samra
jean@laptop-jean:~/repos/lilypond$ git-cl upload origin/master
Documentation/notation/staff.itely | 40
++--
ly/engraver-init.ly| 1 +
2 files changed, 35 insertions(+), 6 deletions(-)
This branch is associated with Rietveld issue 553760043. Adding patch to that
issue.
Message describing this patch set: Add dynamic-interface to keepAliveInterfaces
Upload server: codereview.appspot.com (change with -s/--server)
Your browser has been opened to visit:
https://codereview.appspot.com/get-access-token?port=8001
If your browser is on a different machine then exit and re-run
upload.py with the command-line parameter
--no_oauth2_webbrowser
Issue updated. URL: http://codereview.appspot.com/553760043
We were not able to associate this patch with a tracker issue.
Please enter a valid tracker issue number
(or enter nothing to create a new issue): 5865
Traceback (most recent call last):
File "/home/jean/repos/git-cl/git-cl", line 628, in
sys.exit(main(sys.argv))
File "/home/jean/repos/git-cl/git-cl", line 622, in main
return func(argv[2:])
File "/home/jean/repos/git-cl/git-cl", line 341, in CmdUpload
issueId = projecthosting_upload.upload(issue, patchset, subject, desc,
issueId)
File "/home/jean/repos/git-cl/projecthosting_upload.py", line 192, in upload
status = patchy.upload(issue, patchset, subject, description, issue_id)
File "/home/jean/repos/git-cl/projecthosting_upload.py", line 170, in upload
code_review_url)
File "/home/jean/repos/git-cl/allura_issues.py", line 79, in update_issue
filehandle = urllib.urlopen (allura_api + str(allura_issue_id) + "/save",
data_encoded)
File "/usr/lib/python2.7/urllib.py", line 89, in urlopen
return opener.open(url, data)
File "/usr/lib/python2.7/urllib.py", line 217, in open
return getattr(self, name)(url, data)
File "/usr/lib/python2.7/urllib.py", line 462, in open_https
data)
File "/usr/lib/python2.7/urllib.py", line 381, in http_error
result = method(url, fp, errcode, errmsg, headers, data)
File "/usr/lib/python2.7/urllib.py", line 693, in http_error_401
errcode, errmsg, headers)
File "/usr/lib/python2.7/urllib.py", line 388, in http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 401, 'Unauthorized', )
Re[2]: Patch on dynamics and \RemoveEmptyStaves
Hi "Jean Abou Samra", you wrote My SourceForge username is jean-abou-samra. Could someone please give me write access to the issue tracker? Added as a Developer, with Update and Create permissions in addition to Read. Welcome aboard! Trevor
Re: Patch on dynamics and \RemoveEmptyStaves
Hi Valentin, How strange it sounds to write you in English. Le 24/03/2020 à 19:24, Valentin Villenave a écrit :Hi Jean, some step-by-step instructions are available here: http://lilypond.org/doc/latest/Documentation/contributor/quick-start.html Thanks for the pointer. My SourceForge username is jean-abou-samra. Could someone please give me write access to the issue tracker? Best regards, Jean Abou Samra
Re: Patch on dynamics and \RemoveEmptyStaves
On 3/24/20, Jean Abou Samra wrote: > I have the attached very simple patch for LilyPond. Could anyone please > guide me through the process for patch submission? Hi Jean, some step-by-step instructions are available here: http://lilypond.org/doc/latest/Documentation/contributor/quick-start.html You may not need to use all that, but at least git and git-cl are strongly advised. Good luck, feel free to ask if you have any additional questions! Cheers, V.
Patch on dynamics and \RemoveEmptyStaves
Hi,
I have the attached very simple patch for LilyPond. Could anyone please
guide me through the process for patch submission?
Thanks,
Jean Abou Samra
>From 091ef8928c7c54ac658ad74165e1fa99137aab00 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra
Date: Tue, 24 Mar 2020 15:54:16 +0100
Subject: [PATCH] Add dynamic-interface to keepAliveInterfaces
This will prevent \Remove[All]EmptyStaves from removing
Dynamics contexts containing dynamics attached to spacer
rests but no actual notes (the standard use case
for a Dynamics context).
---
ly/engraver-init.ly | 1 +
1 file changed, 1 insertion(+)
diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
index 450795e298..4df8656690 100644
--- a/ly/engraver-init.ly
+++ b/ly/engraver-init.ly
@@ -762,6 +762,7 @@ automatically when an output definition (a @code{\\score} or
bass-figure-interface
chord-name-interface
cluster-beacon-interface
+dynamic-interface
fret-diagram-interface
lyric-syllable-interface
note-head-interface
--
2.17.1
Re: Issue 2990: \RemoveEmptyStaves in StaffGroup context crashes (issue 7069044)
Reviewers: Keith,
Message:
On 2013/01/10 06:40:08, Keith wrote:
Anything with a line break still causes a crash. I can't say exactly
why,
because I'm a bit confused which VerticalAxisGroup gets removed, the
outer or
the inner.
The outer group commits suicide once it hears of an inner one. I tried
it the other way round first (which would appear to make more sense),
but that made the original report bomb out: possibly one would have
needed to better code the case where an outer group is not happy with
creation of an inner one. It is also possible that this created a
timing problem where the inner group was first created (with the outer
group not being in existence), and then afterwards the outer group being
created and never getting notice of the inner one as its creation time
had already been over.
At any rate, it would appear that listening to the creation messages
(which did not require any additional bookkeeping overhead) is tricky.
If nobody comes up with a oh, this was just missing $x suggestion in
due time, it might provide a cleaner slate for a better fix if this
patch gets reverted.
Description:
Issue 2990: \RemoveEmptyStaves in StaffGroup context crashes
The problem is caused by multiple axis group engravers, and in
particular nested VerticalAxisGroup grobs in connection with the
skyline code. An extensive fix catching any recursive grob definition
will lead to quite more cryptic error messages rather than this
hand-tailored fix for the special case of VerticalAxisGroup nesting.
The solution chosen here is to complain when a VerticalAxisGroup is
announced from a subordinate context and let the current group commit
suicide.
Please review this at https://codereview.appspot.com/7069044/
Affected files:
M lily/axis-group-engraver.cc
Index: lily/axis-group-engraver.cc
diff --git a/lily/axis-group-engraver.cc b/lily/axis-group-engraver.cc
index
10ad7f59922796e33043cca02e1d0f31567400e6..3823c3498484cbe9f1cc9e75a035ee1753284960
100644
--- a/lily/axis-group-engraver.cc
+++ b/lily/axis-group-engraver.cc
@@ -71,6 +71,16 @@ Axis_group_engraver::finalize ()
void
Axis_group_engraver::acknowledge_grob (Grob_info i)
{
+ if (!staffline_)
+return;
+ if (i.grob ()-name () == VerticalAxisGroup) {
+i.grob ()-programming_error (duplicate axis group);
+if (staffline_-is_live ())
+ staffline_-suicide ();
+staffline_ = 0;
+elts_.clear ();
+return;
+ }
elts_.push_back (i.grob ());
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2990: \RemoveEmptyStaves in StaffGroup context crashes (issue 7069044)
On 10 janv. 2013, at 07:40, k-ohara5...@oco.net wrote:
Anything with a line break still causes a crash. I can't say exactly
why, because I'm a bit confused which VerticalAxisGroup gets removed,
the outer or the inner.
\new StaffGroup \with { \RemoveEmptyStaves
} { b1 b1 b1}
{ b1 b1 \break b1 }
My only suggestion is to merge Axis_group_engraver with
Hara_kiri_engraver engraver (and give it a sensible name like
Line_engraver) but that is much more work.
https://codereview.appspot.com/7069044/
It's actually not as bad as you'd think. The Hara_kiri_engraver is just a thin
wrapper around the Axi_group_engraver. Everything can be switched on and off
via an extra context property haraKiri. I was able to drum up a sketch in 10
minutes. Running the regtests now.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2990: \RemoveEmptyStaves in StaffGroup context crashes (issue 7069044)
On 2013/01/10 09:05:21, mike7 wrote: It's actually not as bad as you'd think. The Hara_kiri_engraver is just a thin wrapper around the Axi_group_engraver. Everything can be switched on and off via an extra context property haraKiri. I was able to drum up a sketch in 10 minutes. Running the regtests now. Why would one even need an extra context property? Isn't that what the remove-empty property is already supposed to be for? https://codereview.appspot.com/7069044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2990: \RemoveEmptyStaves in StaffGroup context crashes (issue 7069044)
On 10 janv. 2013, at 10:19, d...@gnu.org wrote: On 2013/01/10 09:05:21, mike7 wrote: It's actually not as bad as you'd think. The Hara_kiri_engraver is just a thin wrapper around the Axi_group_engraver. Everything can be switched on and off via an extra context property haraKiri. I was able to drum up a sketch in 10 minutes. Running the regtests now. Why would one even need an extra context property? Isn't that what the remove-empty property is already supposed to be for? https://codereview.appspot.com/7069044/ Didn't really look into it, as remove-empty is a grob property so I assumed that it was for the actions performed by the grob, not by the engraver making the grob. I'll have a look later. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2990: \RemoveEmptyStaves in StaffGroup context crashes (issue 7069044)
On 2013/01/10 09:21:33, mike7 wrote: On 10 janv. 2013, at 10:19, mailto:d...@gnu.org wrote: On 2013/01/10 09:05:21, mike7 wrote: It's actually not as bad as you'd think. The Hara_kiri_engraver is just a thin wrapper around the Axi_group_engraver. Everything can be switched on and off via an extra context property haraKiri. I was able to drum up a sketch in 10 minutes. Running the regtests now. Why would one even need an extra context property? Isn't that what the remove-empty property is already supposed to be for? https://codereview.appspot.com/7069044/ Didn't really look into it, as remove-empty is a grob property so I assumed that it was for the actions performed by the grob, not by the engraver making the grob. I don't think that is a contradiction. After announcing the grob, overrides, tweaks and so on should be applied to it, and I think that referencing the remove-empty property of the grob at that time in order to decide whether to do the listening and bookkeeping for a harakiri engraver should be fine. I'll have a look later. Thanks. https://codereview.appspot.com/7069044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 2990: \RemoveEmptyStaves in StaffGroup context crashes (issue 7069044)
Anything with a line break still causes a crash. I can't say exactly
why, because I'm a bit confused which VerticalAxisGroup gets removed,
the outer or the inner.
\new StaffGroup \with { \RemoveEmptyStaves
} { b1 b1 b1}
{ b1 b1 \break b1 }
My only suggestion is to merge Axis_group_engraver with
Hara_kiri_engraver engraver (and give it a sensible name like
Line_engraver) but that is much more work.
https://codereview.appspot.com/7069044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Move \RemoveEmptyStaves to new file for context modifications (issue #1760) (issue4664076)
Pushed: cf2da187b5b99e963346e5944311bb77e2e52ff1 http://codereview.appspot.com/4664076/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Move \RemoveEmptyStaves to new file for context modifications (issue #1760) (issue4664076)
2011/7/13 reinhold.kainho...@gmail.com:
Because ly/declarations-init.ly contains:
\layout {
\include engraver-init.ly
}
So the whole contents of engraver-init.ly (including the old definition
of RemoveEmptyStaves) is interpreted and defined inside a layout block
and is thus not available at top-level, just inside any other layout
block...
This patch moves the definition out of the \layout block and thus makes
it available for use inside a score, to.
Ah, i didn't know that making something available at one level can
make it unavailable on other levels.
This part of internal workings of Lily is still mysterious to me.
Thanks for explanation!
So, LGTM.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Move \RemoveEmptyStaves to new file for context modifications (issue #1760) (issue4664076)
Reviewers: ,
Message:
Here's a patch which implements my proposal for a separate context
modifications init file
(http://lists.gnu.org/archive/html/lilypond-devel/2010-07/msg00359.html).
Description:
Move \RemoveEmptyStaves to new file for context modifications.
This allows \RemoveEmptyStaves to be invoked outside \layout blocks,
i.e.,
directly following a context instantiation:
\new Staff \RemoveEmptyStaves { ... }
or
\new Staff \with { \RemoveEmptyStaves } { ... }
* ly/context-mods-init.ly:
new file for context modification identifiers
* ly/declarations-init.ly:
include context-mods-init.ly; placed before engraver-init.ly to ensure
\RemoveEmptyStaves is accessible for deprecated
\RemoveEmptyStaffContext
and analogues
* ly/engraver-init.ly:
remove \RemoveEmptyStaves declaration
Please review this at http://codereview.appspot.com/4664076/
Affected files:
A input/regression/remove-empty-context-mod.ly
A ly/context-mods-init.ly
M ly/declarations-init.ly
M ly/engraver-init.ly
Index: input/regression/remove-empty-context-mod.ly
diff --git a/input/regression/remove-empty-context-mod.ly
b/input/regression/remove-empty-context-mod.ly
new file mode 100644
index
..f1c96ffd7ee9bc66894665ddac3341e2601526ea
--- /dev/null
+++ b/input/regression/remove-empty-context-mod.ly
@@ -0,0 +1,15 @@
+\version 2.15.5
+
+\header {
+ texidoc = @code{\\RemoveEmptyStaves} is defined separately from
+context definitions so it can be used outside of @code{\\layout} blocks.
+}
+
+\paper {
+ ragged-right = ##t
+}
+
+\new Staff \RemoveEmptyStaves {
+ c'1 \break
+ r1
+}
Index: ly/context-mods-init.ly
diff --git a/ly/context-mods-init.ly b/ly/context-mods-init.ly
new file mode 100644
index
..db07600b485cd8aa95f0c93fd5a786ff47a5fbc1
--- /dev/null
+++ b/ly/context-mods-init.ly
@@ -0,0 +1,29 @@
+ This file is part of LilyPond, the GNU music typesetter.
+
+ Copyright (C) 2011 Han-Wen Nienhuys han...@xs4all.nl
+Jan Nieuwenhuizen jann...@gnu.org
+
+ LilyPond is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+
+ LilyPond is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with LilyPond. If not, see http://www.gnu.org/licenses/.
+
+RemoveEmptyStaves = \with {
+ \remove Axis_group_engraver
+ % If RemoveEmptyStaves is called twice, two
+ % Hara_kiri_engravers would be added, which leads to a
+ % warning.
+ % This code makes sure that no previous Hara_kiri_engraver
+ % is left before adding a new one.
+ \remove Hara_kiri_engraver
+ \consists Hara_kiri_engraver
+ \override VerticalAxisGroup #'remove-empty = ##t
+}
Index: ly/declarations-init.ly
diff --git a/ly/declarations-init.ly b/ly/declarations-init.ly
index
268ecaee7eff6de6d34472ced100bbdebb3f3008..8907b789ad674b676cf7af1096bcf9ebf0d2e157
100644
--- a/ly/declarations-init.ly
+++ b/ly/declarations-init.ly
@@ -122,31 +122,29 @@ repeatTie = #(make-music 'RepeatTieEvent)
\include grace-init.ly
\include midi-init.ly
\include paper-defaults-init.ly
+\include context-mods-init.ly
\layout {
-mm = #(ly:output-def-lookup $defaultpaper 'mm)
-unit = #(ly:output-def-lookup $defaultpaper 'unit)
+ mm = #(ly:output-def-lookup $defaultpaper 'mm)
+ unit = #(ly:output-def-lookup $defaultpaper 'unit)
-in = #(* 25.4 mm)
-pt = #(/ in 72.27)
-cm = #(* 10 mm)
+ in = #(* 25.4 mm)
+ pt = #(/ in 72.27)
+ cm = #(* 10 mm)
-\include engraver-init.ly
+ \include engraver-init.ly
-#(set-paper-dimension-variables (current-module))
+ #(set-paper-dimension-variables (current-module))
}
#(set-default-paper-size (ly:get-option 'paper-size))
partCombineListener = \layout {
-\context {
- \Score
- skipTypesetting = ##t
- ignoreBarChecks = ##t
- \alias Timing
-}
+ \context {
+\Score
+skipTypesetting = ##t
+ignoreBarChecks = ##t
+\alias Timing
+ }
}
setDefaultDurationToQuarter = { c4 }
-
-
-
Index: ly/engraver-init.ly
diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
index
d28b8be51b947e1c1391fd37ee7b774be47b8c2c..badb701e08579e8aa7bb4f70ec8b027eaaae0380
100644
--- a/ly/engraver-init.ly
+++ b/ly/engraver-init.ly
@@ -498,20 +498,6 @@ printing of a single line of lyrics.
\override VerticalAxisGroup #'nonstaff-nonstaff-spacing #'padding = #0.5
}
-
-RemoveEmptyStaves = \with {
- \remove Axis_group_engraver
-% If RemoveEmptyStaves is called twice, two
Re: Dynamics context prevents \RemoveEmptyStaves to work
2011/2/9 Neil Puttock n.putt...@gmail.com:
Like this?
\layout {
\context {
\Dynamics
\RemoveEmptyStaves
}
}
Exactly!
Now of course it seems so obvious, I'm wondering *why* I did not think
about this.
Many thanks.
Cheers,
Xavier
--
Xavier Scheuer x.sche...@gmail.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dynamics context prevents \RemoveEmptyStaves to work
2011/2/9 Xavier Scheuer x.sche...@gmail.com:
%% Reported by 胡海鹏 - Hu Haipeng
%% http://lists.gnu.org/archive/html/lilypond-user/2011-02/msg00179.html
%%
%% [empty] Dynamics context prevents \RemoveEmptyStaves to work
%%
%% We should have a way to remove empty Dynamics contexts as well
%% and \RemoveEmptyStaves should remove PianoStaff if both staves and
%% Dynamics are empty.
%%
Like this?
\layout {
\context {
\Dynamics
\RemoveEmptyStaves
}
}
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RemoveEmptyStaves and \with
Le 28 juil. 2010 à 01:50, Reinhold Kainhofer a écrit : Am Dienstag, 27. Juli 2010, um 18:19:39 schrieb Neil Puttock: [..] Why don't we move its definition to a separate file (e.g., `context-modifications-init.ly')? I'm sure there are other mods which could usefully be defined (e.g., \blankStaves for manuscript paper), so a separate home for them makes sense. Good catch! I never used it for a single staff so far, but you are absolutely right... I also think there are several nice context modifications that we can provide pre-built, so users don't have to worry about which engravers to add/remove and which properties need to be set (the issue about placing marks above staff groups rather than the whole score comes to my mind, for example). Right! or to make a smaller staff, e.g. above a piano accompaniment. Nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RemoveEmptyStaves and \with
Hi,
Context modifications inside an identifier are great, but in the case
of \RemoveEmptyStaves, there's a nasty surprise waiting for you: since
it's defined inside a layout block (as part of engraver-init.ly), it's
unusable within a music block.
\new Staff \with { \RemoveEmptyStaves } { c4 }
or
\new Staff \RemoveEmptyStaves { c4 } % even better, gets rid of nasty
\with block :)
- error: unknown escaped string: `\RemoveEmptyStaves'
Why don't we move its definition to a separate file (e.g.,
`context-modifications-init.ly')? I'm sure there are other mods which
could usefully be defined (e.g., \blankStaves for manuscript paper),
so a separate home for them makes sense.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RemoveEmptyStaves and \with
Am Dienstag, 27. Juli 2010, um 18:19:39 schrieb Neil Puttock: Hi, Context modifications inside an identifier are great, but in the case of \RemoveEmptyStaves, there's a nasty surprise waiting for you: since it's defined inside a layout block (as part of engraver-init.ly), it's unusable within a music block. [..] Why don't we move its definition to a separate file (e.g., `context-modifications-init.ly')? I'm sure there are other mods which could usefully be defined (e.g., \blankStaves for manuscript paper), so a separate home for them makes sense. Good catch! I never used it for a single staff so far, but you are absolutely right... I also think there are several nice context modifications that we can provide pre-built, so users don't have to worry about which engravers to add/remove and which properties need to be set (the issue about placing marks above staff groups rather than the whole score comes to my mind, for example). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
