Patrick McCarty wrote Tuesday, May 26, 2009 8:24 AM
On Tue, May 26, 2009 at 07:51:22AM +0100, Trevor Daniels wrote:
Patrick McCarty wrote Monday, May 25, 2009 11:43 PM
On Mon, May 25, 2009 at 03:26:42PM -0700, Patrick McCarty wrote:
On Mon, May 25, 2009 at 2:49 PM, Trevor Daniels
<t.dani...@treda.co.uk> wrote:
>
> The lines in the html version of this section of the
> Notation Reference are significantly longer than any
> other, so long I have to scroll horizontally to read them.
>
> Does anyone else see this, or is it some subtle problem
> with IE?
IIRC, if the line lengths for any <pre> section are too wide,
IE
recalculates the width of the div to accomodate the longest
line on
the page. Other browsers don't behave this way (as far as I
remember).
I suspect the snippet "Non-default tuplet numbers" in the
Tuplets
section is the culprit. If the values of #'text are moved to
separate
lines, that should solve the problem.
And here is a patch.
Patrick
Many thanks, I'm sure your analysis is correct. But like Carl I
find
the patch doesn't apply, although I didn't see his particular
problems.
(Your patch also has 4 lines with trailing white-space, but
that's not
the problem.) Do you want to try again, or should I or Carl
simply fix
it ourselves now you've identified the cause?
Hmm, I can't figure this out.
I just applied my original patch to master (cleanly), and checked
the
snippet (both in input/new and input/lsr) for trailing whitespace.
There was only one line with trailing whitespace. Before applying
the
patch, the two files still only containing one line with trailing
whitespace.
However, the *patch* contained trailing whitespace on some of the
empty lines as well, but it still applied cleanly for me.
Maybe this is a bug in "git format-patch" in my installed git
verson
(1.6.3.1). It seems odd that "git format-patch" would add
trailing
whitespace.
I created a fresh patch and manually removed all of the trailing
whitespace from it, except for the one in the texidoc which I
fixed.
Let me know if this one works.
'Fraid it doesn't. This one fails with "fatal: corrupt patch at
line 11".
This is the usual effect of editing a patch file manually.
I've looked again more closely at your original patch. The reason
it fails to apply is that line 45 in the existing version of
/input/lsr/non-default-tuplet-numbers.ly has no trailing space
(actually
it's just a single blank line), but your patch attempts to match it
with
a line containing a single space. The same is true of line 13 in
/input/new/non-default-tuplet-numbers.ly. There may be more; I
think git am reports just the first one in each file.
When I edit files from git I make sure there are no trailing spaces
by setting my editor to remove them automatically.
Trevor
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
