]> git.donarmstrong.com Git - lilypond.git/blobdiff - Documentation/user/tweaks.itely
Update from Carl.
[lilypond.git] / Documentation / user / tweaks.itely
index 387d119fec5b621ee2af8c94835bb26268798a10..d1078b1c4dab09e175d67869f0f2ef61cfb9bb62 100644 (file)
@@ -2997,8 +2997,6 @@ lhMusic = \relative c' {
 * Other sources of information::  
 * Avoiding tweaks with slower processing::  
 * Advanced tweaks with Scheme::  
-* context list FIXME::          
-* another thing FIXME::         
 @end menu
 
 @node Other uses for tweaks
@@ -3372,174 +3370,3 @@ can be found in @ref{Tweaking with Scheme}.
 
 
 
-
-@node context list FIXME
-@subsection context list FIXME
-
->> > > - list of contexts: my *danger unmaintainable* 
->> > > alarm just went off.  I'm 
-
-I knew it would... And leaving out some of them is perfectly fine
-with me.
-I do think that a list like this, with the main contexts and a
-brief
-description of  what they do (perhaps also with a note about what
-default
-behavior is associated with each of them, but this may be
-unmanageable),
-should be there, and then we could simply list the remaining ones
-without
-further explanation and with links to the IR.
-
-
-The Master Of All Contexts
-==========================
-
-    * Score
-        This is the top level notation context. No other context
-can
-        contain a Score context. This context handles the
-        administration of time signatures. It also makes sure that
-        items such as clefs, time signatures, and key-signatures
-are
-        aligned across staves.
-        You cannot explicitly instantiate a Score context (since
-it is
-        not contained in any other context). It is instantiated
-        automatically when an output definition (a \score or
-\layout
-        block) is processed. 
-        (it should also be made clear somewhere what the
-difference is between
-        \score and \Score).
-
-Top-level contexts: Staff containers
-====================================
-    * StaffGroup
-        Groups staves while adding a bracket on the left side,
-        grouping the staves together. The bar lines of the
-contained
-        staves are connected vertically. StaffGroup only consists
-of a
-        collection of staves, with a bracket in front and spanning
-bar
-        lines.
-    * ChoirStaff
-        Identical to StaffGroup except that the contained staves
-are
-        not connected vertically.
-    * GrandStaff
-        A group of staves, with a brace on the left side, grouping
-the
-        staves together. The bar lines of the contained staves are
-        connected vertically.
-    * PianoStaff
-        Just like GrandStaff but with a forced distance between
-the
-        staves, so cross staff beaming and slurring can be used.
-    * DrumStaff
-        Handles typesetting for percussion. Can contain DrumVoice
-    * InnerStaffGroup
-    * InnerChoirStaff
-
-Staff-level contexts
-====================
-    * Staff
-        Handles clefs, bar lines, keys, accidentals. It can
-contain
-        Voice contexts.
-    * RhythmicStaff
-        Like Staff but for printing rhythms. Pitches are
-        ignored; the notes are printed on one line.
-    * TabStaff
-        Context for generating tablature. By default lays the
-music
-        expression out as a guitar tablature, printed on six
-lines.
-    * VaticanaStaff
-        Same as Staff, except that it is accommodated for
-        typesetting a piece in gregorian style. 
-    * MensuralStaff
-        Same as Staff, except that it is accommodated for
-        typesetting a piece in mensural style. 
-
-Voice-level (bottom) contexts
-=============================
-What is generated by default here?  The voice-level contexts
-initiate
-certain properties and start engravers. 
-
-    * Voice 
-        Corresponds to a voice on a staff. This context handles
-the
-        conversion of dynamic signs, stems, beams, super- and
-        subscripts, slurs, ties, and rests.
-        You have to instantiate this explicitly if you want to
-have
-        multiple voices on the same staff. 
-        Bottom context.
-    * VaticanaVoice
-        Same as Voice, except that it is accommodated for
-        typesetting a piece in gregorian style.  
-    * MensuralVoice
-        Same as Voice, except that it is accommodated for
-        typesetting a piece in mensural style. 
-    * Lyrics
-        Corresponds to a voice with lyrics. Handles the printing
-of a
-        single line of lyrics.
-        Bottom context.
-    * DrumVoice
-        A voice on a percussion staff.
-    * FiguredBass
-         
-    * ChordNames
-        Typesets chord names.  This context is a `bottom' context;
-it
-        cannot contain other contexts.
-
-------------------------------
-Then the following, which I don't know what to do with:
-
-    * TabVoice
-    * GregorianTranscriptionVoice
-    * GregorianTranscriptionStaff
-
-    * FretBoards
-        Engraves fretboards from chords. Not easy... Not
-documented.
-    * NoteNames
-
-    * CueVoice Not documented
-    * Global
-        Hard coded entry point for LilyPond. Cannot be tuned.
-    * Devnull
-        Silently discards all musical information given to this
-context.
-
-
-@node another thing FIXME
-@subsection another thing FIXME
-
-Another thing that is needed, is an overview of the various naming
-conventions: 
-
-    scheme functions: lowercase-with-hyphens (incl. one-word
-names)
-    scheme functions: ly:plus-scheme-style
-    music events, music classes and music properties:
-as-scheme-functions
-    Grob interfaces: scheme-style
-    backend properties: scheme-style (but X and Y!)
-    contexts (and MusicExpressions and grobs): Capitalized or
-CamelCase
-    context properties: lowercaseFollowedByCamelCase
-    engravers:
-Capitalized_followed_by_lowercase_and_with_underscores
-
-Which of these are conventions and which are rules?
-Which are rules of the underlying language, and which are
-LP-specific?
-
-
-