From a brand-new user perspective, I think Han-Wen is on the right track.
Leave the links, but make their order consistent and meaning clearer. ie, not just
see also
1
2
3
but rather see also grob 1 guts 2 etc 3
I'm only still learning that X_engraver and X-event actually tells me a lot about where the link points; consistent, labelled references would allow me to inductively discover this much more quickly.
.02 cents (no pun intended) :-)
Happy Friday!
Han-Wen Nienhuys wrote:
Graham Percival wrote:On 12-May-05, at 2:40 AM, Han-Wen Nienhuys wrote:Graham Percival wrote:What's this? How is \displayMusic supposed to work?I guess the Event types can be ditched if somewhere it is explained clearly that you can doI favor this solution. Is this ok?Maybe one alternative is to skip the links to the music expressions (*Event) all together since they can be found by navigating Arpeggio -> Arpeggio_engraver -> arpeggio-event. This would also reduce the number of links that have to be kept up to date manually in the manual.
\displayMusic ...
and see what's inside.try \displayMusic { c4-\arpeggio }The main proposal here is that instead of having this:My worry is that encouraging people to find out thngs on their own in the program-reference on their own might also not be productive. If you think many links is confusing, than it would be best not to have them browse the internals page (with its many links.)
Arpeggios
blah blah
@seealso
_ArpeggioEvent_, _Arpeggio_
we just have this:
Arpeggios
blah blah
@seealso
_Arpgeggio_
If a user wants to see the internals stuff, he clicks on _Arpeggio_. The very first line tells
him that Arpeggio objects are created by Arpeggio_engraver and Span_arpeggio_engraver;
following those links will get him to arpeggio-event. We don't need a link to
arpeggio-event in the refman page about Arpeggios.
_______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
