Issue 2917: Extend \keepWithTag to allow multiple tags

Issue 2917: Extend \keepWithTag to allow multiple tags

Also extends \removeWithTag accordingly.


There are also a few other commits from issue 2883 drawn in.  The set
is slightly larger than necessary for this issue, but I wanted to
avoid having to manually resolve merge conflicts.

Replace the rather fuzzy list-or-symbol? with symbol-list-or-symbol?

list-or-symbol? was previously used in the meaning of
symbol-list-or-symbol? only, and there is no point in not checking the
list members for actually being symbols, in order to avoid ugly
surprises later.

Add symbol-list-or-music? predicate

This is of interest for commands like \hide which accept either music
(to see an override) or a grob specification like Accidental or
Voice.Accidental.

Add symbol-list? predicate

[lemzwerg, 2012-10-23 11:19:59]

LGTM.  Any convert rules necessary?

[dak, 2012-10-23 11:35:57]

On 2012/10/23 11:19:59, lemzwerg wrote:
> LGTM.  Any convert rules necessary?

Well, I abolish list-or-symbol? here on the assumption that nobody used this
peculiar and mostly ill-advised predicate.  That is somewhat optimistic. 
Converting list-or-symbol? automatically to symbol-list-or-symbol?, however,
would silently change its meaning.  So I'd not really be all that comfortable
with that.  If that predicate is indeed needed, it is trivial to write.  One
could retain it under the old name, but it really is too unspecific to be of
good use.

[marc, 2012-10-23 19:05:09]

Hey, that was quick! Thanks for solving this issue - LGTM!

[dak, 2012-10-23 19:45:15]

On 2012/10/23 19:05:09, marc wrote:
> Hey, that was quick! Thanks for solving this issue - LGTM!

Well, there is no regtest and no documentation, so it is not like there is
nothing left to do.  And to be honest, the usual "to check this feature, you
have used some code and could equally well turn this into a regtest" does not
even apply.  I haven't checked anything.

[marc, 2012-10-24 06:42:39]

On 2012/10/23 19:45:15, dak wrote:
> On 2012/10/23 19:05:09, marc wrote:
> > Hey, that was quick! Thanks for solving this issue - LGTM!
> 
> Well, there is no regtest and no documentation, so it is not like there is
> nothing left to do.

That's right – we had this discussion before concerning new
features and the documentation part. The 'LGTM' is just meant
for the code you uploaded for review – I like the way you
rework parts of lilypond on-the-fly while adding new features
instead of just adding a lot of new stuff (as I had probably
done it).

  And to be honest, the usual "to check this feature, you
> have used some code and could equally well turn this into a regtest" does not
> even apply.  I haven't checked anything.

This cannot be seen by reviewing this patch alone, so I had
to trust on you ;-)

[janek, 2012-10-24 09:58:12]

LGTM

shall the tracker issues "write doc for this" and "add a regtest for this" be
added now or after this patch is pushed?
(my concern is to make sure that we won't forget)

cheers,
Janek

[dak, 2012-10-24 10:07:25]

On 2012/10/24 09:58:12, janek wrote:
> LGTM
> 
> shall the tracker issues "write doc for this"

It is not as much "write doc for this" as the function itself has its docs
updated.  It is more "update the existing docs in the manual to reflect the
change".

> and "add a regtest for this" be
> added now or after this patch is pushed?
> (my concern is to make sure that we won't forget)

I am not planning on working on this myself but that does not preclude someone
else from submitting the respective parts which I would then incorporate into
the patch.  So I would lean towards waiting with creating the doc/regtest issues
until the patch is indeed being pushed.

[pkx166h, 2012-10-24 15:29:00]

On 2012/10/24 10:07:25, dak wrote:
> On 2012/10/24 09:58:12, janek wrote:
> > LGTM
> > 
> > shall the tracker issues "write doc for this"
> 
> It is not as much "write doc for this" as the function itself has its docs
> updated.  It is more "update the existing docs in the manual to reflect the
> change".
> 
> > and "add a regtest for this" be
> > added now or after this patch is pushed?
> > (my concern is to make sure that we won't forget)
> 
> I am not planning on working on this myself but that does not preclude someone
> else from submitting the respective parts which I would then incorporate into
> the patch.  So I would lean towards waiting with creating the doc/regtest
issues
> until the patch is indeed being pushed.

NR Doc tracker is here

http://code.google.com/p/lilypond/issues/detail?id=2922

I think someone who knows better than I ought to make the regression test.

James