Re: Don't treat context modification identifiers special (issue 299460043 by address@hidden)

[dak]

On 2016/07/02 14:19:31, Dan Eble wrote:
> LGTM, though I rarely work with yacc.  Requiring \with is a good idea.

> I don't appreciate the value of \with #*unspecified*. Does it parallel
a feature
> that was already used in context mod lists?

If there is need for discussion, I can move this change into a separate
issue.  It is indeed almost entirely orthogonal to this issue here.  To
be honest, it has been sitting in a branch of its own since, uh,
September 2013.  The motivation to finally add it to a submission was
that we have a number of situations where

#(if condition expression)

works and is silently ignored when the whole of it evaluates to
*unspecified* (which it will when the condition is false).  For example,
you could previously have written

\with { ... #(if ... #{ \with { ... } #}) ... }

and it would have done nothing if the condition evaluated to false.
However, if you now add redundancy as

\with { ... \with #(if ...) ... }

it would stop working.  Since the motivation for adding \with to context
modification expressions has now become a bit stronger, I had somewhat
more motivation to extend the "unspecified means nothing" pattern here.

> I glossed over the convert-ly change.

It's a bit fishy since it first tries to find context modification
definitions obeying a certain pattern before trying to replace all
\with-less context modifications to explicit context starts.  Obviously,
there is a whole lot of ways of defining context modifications, and
definition and use need not happen in the same file.

And, uh, this does not catch context modifications added to \chords,
\lyrics, \addlyrics etc.  Uh.  I think I need to extend that rule, come
to think of it.  I'll do that.  Which should give some time to see
whether people would rather have the \with #*unspecified* change forked
out to facilitate separate discussion and/or removed altogether.

https://codereview.appspot.com/299460043/