On 2012/08/04 08:06:38, Trevor Daniels wrote:
On 2012/08/03 09:35:47, dak wrote:
> The obvious way would be to reorganize into fewer layers.
No. This is a long and complicated subsubsec
Reorganizing into fewer layers would mean reorganizing the containing
structure so that we don't already end up in a subsubsec.
and the point
of this issue is to improve clarity. The best way of doing
that is to introduce structure into the very long text.
A very long text is not suitable as a subsubsec.
In particular we need to clearly distinguish the two methods of
controlling automatic beaming so they can be contrasted and
referenced.
> That @i{} stuff is not really good: it has the wrong
> spacing and penalties for a heading. For example, it
> might get separated by a page break from its following
> text.
This is a drawback, but not a disaster -- it might not
happen.
A disaster waiting to happen is not a great thing. In particular since
it will tend to happen undercover. People are not likely to recheck all
page breaks just because they change an unrelated section some place
above.
> It will also usually be followed by indented text
> as opposed to normal headings. And will probably
> be indented itself.
Neither it nor the following text are indented in html.
In pdf the heading is indented, but in my view this is
not detrimental to its purpose.
A heading indented as opposed to the following main paragraph shape?
Ugh, ugh, ugh.
Far worse would be
to use @unnumberedsubsubsec or @subsubheading as these
all look identical in pdf and the intended structuring
is lost.
So on balance we should go with @i{@strong ..}} as the
best of the poor choices available.
I don't see any balance at all. It is not like anything precludes you
from using @unnumberedsubsubsec @i{@strong ...} so it is not like using
the heading commands for getting proper header distances, page breaks
and indentation precludes you from additional markups.
But again: the real issue to me seems that we are hiding a long chapter
inside of a subsubsec already.
http://codereview.appspot.com/6452072/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
