Thomas Morley <thomasmorle...@googlemail.com> writes: > Hi, > > accidently I noticed that DevNull produces some weird output, if its > argument contains an override to TabStaff, VaticanaStaff or > RhythmicStaff (this list may be not complete) > > \version "2.17.4" > > mus = { > \override TabStaff.TabNoteHead #'color = #red > % same with: > % \override VaticanaStaff.NoteHead #'color = #red > % \override RhythmicStaff.NoteHead #'color = #red > % but not with, p.e.: > % \override Staff.NoteHead #'color = #red > c1 > } > > \score { > << > \new Devnull \mus > %\new Staff \mus > %\new TabStaff \mus > %\new VaticanaStaff \mus > %\new RhythmicStaff \mus > >> > } > > Is this a bug (in this case I'll create a bugreport) or expected behaviour?
It is pretty much expected behavior. The output is the same as \score { << \new TabStaff {} \skip 1 >> } which spends, in the grand total of things, a time of a whole note and creates a TabStaff. The definition of Devnull is \context { \name "Devnull" \type "Engraver_group" %% don't want to route anything out of here: \alias "Staff" \alias "Voice" \description "Silently discards all musical information given to this context." } and it is accepted by \Score. So it will capture overrides to Staff and Voice (and Devnull), but anything else will create a context of the appropriate type in the containing \Score context and direct the override there. To change this, Devnull would either need to contain more aliases, or it would need to \accept the respective contexts itself or have a \defaultchild accepting them. But in the latter cases, those contexts would be fully operative, defeating the idea of Devnull. Should Devnull try to be an alias for every context type? Good question. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user