Carl Sorensen wrote Friday, November 26, 2010 6:43 PM
On 11/26/10 10:51 AM, "Valentin Villenave"
<valen...@villenave.net> wrote:
Please have a look at the attached patch:
http://dl.free.fr/pMyOkyICo
I like the new patch, I think. I believe that it
would be preferable to do this instead of reverting
the previous patch.
OK; I agree. Patch looks good.
Er, are you suggesting that
@file{this/is/a/very/long/path/towards/myfile.scm}
should be printed without a line break?
I am suggesting this. I would much prefer to keep file paths on
one line as
long as they fit.
Yes, /as long as they fit/, but fit into what?
Hhm. Not sure. I think I'd prefer "more than three dashes or
slashes",
if we are to do it that way, but really it depends more on the
total length
of the name rather than the number of dashes and slashes. I'd
prefer
"if the name is longer than 50 characters (say)".
And if the name is too long then I'd prefer to place a single
optional break
near to the middle, so we don't get tiny fragments at the end or
start of
lines.
Both suggestions seem reasonable and easy enough to achieve.
(50 chars are really long, though.)
But a file name really *is* a single piece of information, so it
should be
kept on one line. If it's so long it won't fit on one line, then
we should
decide where to break it, rather than having it be done
automatically at any
slash.
Ideally, yes. But who is going to look manually through
all the docs? Better to do it automatically first, then
fix up any that stand out as poor when we notice them.
Otherwise we might have some names running over the right
margin in 2.14. Don't forget we've now lost the ones
that were done manually before - and some of them /were/
correct.
Trevor
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel