Menu

#1322 \context must die (whenever \new can be used instead)

Accepted
nobody
Syntax (9)
Documentation
2015-04-27
2010-10-12
Anonymous
No

Originally created by: *anonymous

Originally created by: v.villenave

There really are only two cases where \context is acceptable:
  - when introducing a block inside \layout { ... }
  - when referring to an existing, /explicitely named/ context.

The first case is off the table.

The second possibility, of course, is much less frequent/useful/used at all. Truth is, most of the time people use \context instead of \new without any good reason whatsoever, which leads to syntax inconsistencies.

The documentation isn't entirely clear either: for instance, NR 5.1.2 "Creating contexts" has the following example
<<
  \new Staff \context Voice = "A" \music
  \context Voice = "A" \arts
>>

where \new would be more appropriate when creating the Voice:
<<
  \new Staff \new Voice = "A" \music
  \context Voice = "A" \arts
>>

Another example: NR 1.1.3.5 Automatic accidentals uses the following example:
\new PianoStaff {
  <<
    \context Staff = "up" {
      #(set-accidental-style 'default)
      \musicA
    }
    \context Staff = "down" {
      #(set-accidental-style 'default)
      \musicB
    }
  >>

It's also used a lot in LM snippets (templates, etc.).

---

It's not uncommon that users (particularly new users, or users who have been using older versions in the past, when the syntax was different) encounter problems (and ask for help) just because of that.  So we definitely need to:
  - discourage this syntax (unless specifically needed, which is quite advanced and pretty rare -- in fact, I've yet to see a case where it actually is)
  - clean up the docs/regtests (and possibly snippets), just like we did with \new Score.
  - I even wonder if a warning could be issued by convert-ly when it encounters \context outside of a \layout block?

Discussion

  • Google Importer

    Google Importer - 2010-10-12

    Originally posted by: percival.music.ca@gmail.com

    WTF?  I haven't agreed to this, nor have I seen any discussion on the topic.  And I don't think it's worth going on a huge manhunt for these things when the syntax might be changing in a few months anyway!

    I'll mark this "postponed" instead of "invalid", but nobody should work on this yet.

    Labels: -Priority-Medium Priority-Postponed

     
  • Google Importer

    Google Importer - 2010-10-12

    Originally posted by: percival.music.ca@gmail.com

    I took about 30 seconds to think about it.

    - to the best of my lilypond knowledge,
        <<
          \new Staff \context Voice = "A" \music
          \context Voice = "A" \arts
        >>
      is perfectly valid.

    - I can't recall seeing any problems on -user that arose because of \context instead of \new.

    - having two different ways of doing something is no cause for alarm.

    - GLISS might deprecate the \context{} method, or might have a different syntax than \new, so I hardly see the point in changing this right now.

    - it's less important than most priority-low items.  Issue 1245, issue 673, issue 1015, and issue 1189 are more important.  Admittedly it's on par with issue 965.

    I spent a few minutes poking around in the sources, and estimate that it would take James about 5 hours.  I really don't this as a good payoff-to-work ratio, especially given GLISS.

     
  • Google Importer

    Google Importer - 2010-10-12

    Originally posted by: Carl.D.S...@gmail.com

    I actually *prefer* to use

    \context Staff = "upper"

    instead of

    \new Staff = "upper"

    If  I use \context Staff = "upper", then if I already have an upper staff defined, it doesn't create a new one.  That's the behavior I want.  This is very convenient when combining multiple input files in different ways to produce multiple editions.

    What is the problem you see with using \context Staff = "upper", or the equivalent?  Why make the user decide what is the first use of a particular context, when the parser can do it just fine?

    In my opinion, the only time \new should be used is when creating *unnamed* contexts.

    Since we have the difference of opinion on this, it seems to me to be very premature to be proposing that we root out valid syntax from the documentation.

    I'll be happy to have this discussion as part of GLISS.

     
  • Google Importer

    Google Importer - 2010-10-12

    Originally posted by: Carl.D.S...@gmail.com

    Also, why do you say that \context should only be used when referring to an *existing* explicitly-named context?

    One of the great things about using \context is that it creates a new explicitly-named context if it doesn't already exist.  That's why I like it so much.

     
  • Google Importer

    Google Importer - 2010-10-12

    Originally posted by: percival.music.ca@gmail.com

    Good points, Carl.  One GLISS possibility is to do away with \new and \context altogether:
    \score {
      \PianoStaff <<
        \Staff = "upper" { c'4 }
        \Staff = "lower" { c4 }
      >>
    }

    although for some reason I want to write \pianoStaff and \staff with a lower-case beginning.  Maybe I've done too much C++ coding with camelCase.  :)

     
  • Google Importer

    Google Importer - 2010-10-13

    Originally posted by: tdanielsmusic

    We can't so that (do away with \new and \context).  The context names
    would then have to be defined in the parser, preventing users from
    creating their own contexts.

    Trevor 

     
  • Google Importer

    Google Importer - 2010-10-13

    Originally posted by: v.villenave

    Carl:
    > This is very convenient when combining multiple input files
    > in different ways to produce multiple editions.

    This is more or less what I referred to as "quite advanced and pretty rare". I certainly do not question the way you organise your files, and it is even possible that most users, when reaching a certain level, use the same feature. But those are not the kind of beginners asking for help on -user, where I've rarely seen anyone using \context appropriately.

    Unlike \new, \context may produce unwanted results when used with anonymous contexts. I've just found an example:
    http://lists.gnu.org/archive/html/bug-lilypond/2010-10/msg00245.html
    You may (rightly so) object that users *should* name their contexts anyway, but then your "why make the user decide" question becomes "why force the user to name their contexts, when the parser can do without it just fine"? :-)

    Graham:
    Of course using \context Staff = "blah" is valid.  But then again, so is \new Score \with {foo = #bar}. Yet you've just deprecated this syntax (as I myself suggested a while back: http://lists.gnu.org/archive/html/bug-lilypond/2010-03/msg00054.html ).

    I'm not suggesting that we should remove any feature. I'm just saying that we should encourage new users to preferably use \new, unless they really know what they're doing and what they need (named) \context for.

     
  • Google Importer

    Google Importer - 2010-10-13

    Originally posted by: Carl.D.S...@gmail.com

    As Trevor posted in the list (but not on the issue here), a change requiring \context to include a name for the context would be appropriate.

    I don't think we should encourage new users to use \new for named contexts; I think we should encourage users to use \new for anonymous contexts.

    Anonymous contexts, by their very nature, can't be reused in another included file.  Hence, it makes sense to use \new for them -- we want a new context, we don't care what its name is, and its life will be limited to this file.  Anonymous contexts also can't be selected somewhere else in the same file.  And the purpose of \context is to select a context, so it doesn't make sense to be used with anonymous contexts.

    Named contexts, on the other hand, can be reused.  And they can exist in multiple files, to be combined by inclusion.  Since they can exist in multiple files, we have no idea when the context is created (but the iterator does).  And they can be selected elsewhere.

    So I'd propose that we set our standard that anonymous contexts are created with \new, and named contexts are created (and selected) with \context.

    If the summary of the issue were changed to "\context must be used only with named contexts", I'd be totally on board.

     
  • Google Importer

    Google Importer - 2010-10-13

    Originally posted by: tdanielsmusic

    I'm with Carl, except I think I'd prefer \new to continue working if the
    context is named, /provided/ that the context does not exist.  If the named
    context does exist I'd prefer \new to fail (although maybe it would be more in
    keeping with the LilyPond style if it worked as if it were \context but gave a warning.)

    Trevor

     
  • Google Importer

    Google Importer - 2010-10-13

    Originally posted by: percival.music.ca@gmail.com

    @comment 7 Trevor:
    it's not impossible to let a user add items to the parser.  I'm claiming this would be easy, or that it might require a fundamental rewrite of basic lilypond stuff, or that it would even be a good idea, but I don't think that we should outright reject the idea of letting people define \mystaff.

    Once the topic arises in GLISS, I'm quite open to the argument "this would require about 100 hours of work, and the benefit isn't worth it", or "ok, we _could_ add this ability with 50 hours of work, but it would make all code compile 200% slower, so it wouldn't be worth it".  But I want to keep it on the table until we officially reject it with sound reasons.  (and then if the topic comes up again, we can point people at the reasons why we rejected the idea, and then they know what kind of patch / speed penalty would be involved, and try to overcome those technical difficulties on their own if they want to raise the parser-modifying idea again)

    @Carl:
    I don't see any logical connection between "\new" and "anonymous".  I do, however, see a connection between "\new" and "creating something".  Maybe the functionality of "\new" should be achieved with a differently-named command?  (\anonymous ? nah, no non-functional-programmer would understand it)  or maybe isolate the "named context" idea -- have a \named Staff "foo" vs. \unnamed Staff ?

    I've added a link to this issue in the list of GLISS specifics.  You can verify this here:
    http://lilypond.org/~graham/gliss/specifics.html

     
  • Google Importer

    Google Importer - 2010-10-24

    Originally posted by: n.putt...@gmail.com

    > a change requiring \context to include a name for the context would be appropriate

    We can't do this, since it would prevent context specification for \applyContext (unless the user implements it directly in scheme).

    This is perfectly valid:

    \new Staff \relative c' {
      c1
      \context Timing
      \applyContext #(lambda (ctx)
                       (newline)
                       (display (ly:context-current-moment ctx)))
      c1
    }

     
  • Google Importer

    Google Importer - 2015-04-27

    Originally posted by: simon.al...@mail.de

    (The link at the end of comment #11 is broken)

     
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.