lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RemoveEmptyStaffContext erases previous setting


From: Reinhold Kainhofer
Subject: Re: RemoveEmptyStaffContext erases previous setting
Date: Mon, 8 Feb 2010 15:45:54 +0100
User-agent: KMail/1.12.4 (Linux/2.6.31-19-generic; KDE/4.3.5; i686; ; )

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 05 February 2010 18:37:10 Reinhold Kainhofer wrote:
> Anyway, I'll see if I can find a way to recode RemoveEmptyStaffContext to not 
> store the whole Staff context at definition time, but only apply the desired 
> settings when called. I suspect that some Scheme magic might be able to do 
> the trick.

Okay, I'm running into several problems. Hopefully someone has an idea how to 
proceed...

1) The main probem for the RESC is that it is a variable and is evaluated when 
it is defined. Ideally, there would be a way to define a function/macro RESC 
that is stored, but only evaluated when it is "called" (i.e. found by the 
parser). I haven't seen anything like this in lilypond yet, but it would 
definitely be the best solution.
I.e. 
      \context { \RemoveEmptyStaffContext }
should be exactly the same as explicitly writing **at that position** in the 
code:
\context {\Staff 
  \remove "Axis_group_engraver"
  \consists "Hara_kiri_engraver"
  \override Beam #'auto-knee-gap = #'()
  \override VerticalAxisGroup #'remove-empty = ##t
}

(i.e. the parser inserts not the pre-stored context-def, but the code and 
evaluates the code at that place).


2) The parser is very strict about what can be inside a \context {..} block. 
In particular, no scheme code or other function is allowed. Basically, the 
only things allowed are:
  -) a context name
  -) a variable holding a context-def (apparently not a function returning a 
     context-def, which would solve the problem)
  -) explicit context modifications (i.e. context prop assignments XXX=YYY and 
     lines explicitly starting with the usual keywords \consists, \remove, 
     etc.) Again, no scm code returning context modifications is allowed.


3) There is no scheme interface (yet) for context-def.


I'm hoping I'm missing something and there is a way to define a parser 
macro/function, which is evaluated / expanded when it is found by the parser 
(i.e. solving 1). 


If that's no possible, what do you think would be the best solution:

a) Allowing scheme code inside a \context block and defining a scheme function, 
which evaluates
  #{\context {\Score
      .....
    } #}
at that position and returns the context-def, which is then used by the 
parser.

or 
b) Providing a scheme interface for context modifications and implementing RESC 
as a global function, which obtains the Staff context-def via find_context_def, 
modifies it accordingly and calls assign_context_def (both via new scheme 
interface).

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: address@hidden, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * Edition Kainhofer Music Publishing, http://www.edition-kainhofer.com/
 * LilyPond music typesetting software, http://www.lilypond.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktwI6IACgkQTqjEwhXvPN0u5QCfX2BpCL8yha+PXi4aZbvQBdrr
oswAoJchidwNlyQOUvbjuSoQ2wcJSh3/
=FGhk
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]