Marc Hohl wrote:
> Yes, I knew that, but I found other sources with one more
> squiggle, which looked more pleasant to me - but that's my
> personal opinion.
Why not have the option for both? You could set up
something like:
\override Score.BarLine #'segno-style = #'default
\override Score.BarLine #'segno-style = #'alternative
Then you wouldn't have to add any new syntax to the \bar
command.
>> 3) again in the bar-line interface docstring, if
>> @code{...} isn't inside its own set of parentheses
>> "(@code{...})", @samp{...} is better. However, glancing
>> around I see that none of the other docstrings do this,
>> so maybe that should be addressed separately.
> So I must not change anything, do I?
Right. Leave it alone for now.
>> 4) do you need to make a regression test?
> I did; see input/regression/bar-line-segno.ly - or do you
> mean this isn't necessary?
Sorry. I did `git apply' and forgot to do `git add' so I
didn't see it there.
>> 5) you should also mention this in changes.tely
> Ok. I also dropped a line about the tablature changes.
> Perhaps this is too little but I think this should be
> addressed to in another patch, if necessary.
My preference is to keep things like that in a separate
patch. It makes the git history easier to navigate. I
would remove the tab stuff from this patch.
Lastly, you're patches contain whitespace errors. I've set
up vim to remove trailing whitespace with every write, but
you could run `scripts/auxiliar/strip-whitespace.py' on your
files before you commit them, if that's easier. What editor
are you using?
- Mark
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
