A differently phrased answer to the same question:
All commands, like \time, \override, \new, \score, ... are (?) listed
in the index of the manual. In addition, you have all different
properties, both so-called
context properties and layout object properties. These can be found via
Program Reference -> Translation -> Tunable context properties
and Program Reference -> Backend -> User backend properties,
respectively. However, the relevant properties can often more
conveniently be found via links in the manual. A general description on
how to set these properties and find
out the available properties and values for some specific feature
can be found in the chapter on "Changing Defaults".
/Mats
Quoting Graham Percival <[EMAIL PROTECTED]>:
On 6-Apr-06, at 9:48 AM, Rick Hansen (aka RickH) wrote:
Is there a document or appendix that simply lists all reserved words that
could possibly occur in an .ly document and their definition, and what
"type" of constant or funtion or macro, etc. the reserved word is, also if
it's been depricated, renamed, etc. across versions? IOW All reserved words
in alphabetical order no matter what "type" of word it is.
No, we don't have one.
In the next few months, we might get a separate index of all commands
that are present in the manual (instead of commands and concepts
being mixed together in the index). Within the next few weeks, I'll
improve documentation on how to find out more about macros (ie
looking at ly/property-init.ly and related files). Note that
macros like this (such as \slurUp) are not reserved words; you can
redefine them if you wish.
Listing depricated and renamed words across all versions will not
happen. Interested users could read python/convert-rules.py and/or
read the NEWS files, but I cannot possibly imagine that a list of all
these would be interesting enough to warrent the amount of time and
effort required to create it.
Such a list would be useful once one learns the basic concepts in the user
manual.
It might be useful, but at this point I prefer to take a very
realistic view of documentation -- namely, if it's not something I
can finish in a few hours, it isn't going to get done. Sorry to be
so abrupt, but I've been burned by this issue too many times.
A brief history of LilyPond documentation: every 4-6 months, somebody
comes up with a great idea for the docs. Completely rewriting the
tutorial is a common one; we've also had things like ``really
detailed clickable examples'', ``annotated three-page examples'', and
the like. Every time these ideas come up, we spend a few hours
reading and writing emails about it. And a few weeks after the
discussion, nothing has happened and everybody's forgotten about it.
A few months ago, I realized that I was spending more time discussing
the documentation than actually *working* on the docs. At this
point, I'm not looking for new doc ideas, unless I ask for ideas on a
specific issue.. I have about a month's work of my own ideas to do
on the docs.
If you're offering to write this documentation, it's a completely
different story, of course. :) I'm willing to spend a lot of time
discussing or helping people who are writing docs.
Cheers,
- Graham, LilyPond Documentation Editor
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
