On Dec 26, 2012 10:49 AM, "David Kastrup" <d...@gnu.org> wrote: > > Colin Hall <colingh...@gmail.com> writes: > > > David Kastrup <dak <at> gnu.org> writes: > > > >> > >> Richard Shann <richard.shann <at> virgin.net> writes: > >> > >> > On Sat, 2012-12-22 at 00:58 +0100, David Kastrup wrote: > >> > I guess this $ notation is documented somewhere - searching around > >> > yesterday evening I came across this > >> > http://lilypond.org/doc/v2.16/Documentation/notation/expressive-marks- > > attached-to-notes#index-DynamicText > >> > > >> > which is where I suspect I got the notation I was using. Should that be > >> > using $ too > >> > >> I repeat: with the exact given examples in the manual, the location data > >> is correct. > > > > Thanks for your help with this, David, it looks like > > Richard is able to engrave his music. > > > > Could you give me some advice on forming a good > > documentation enhancement tracker for > > the "$(" syntax? Perhaps there's a description > > in a commit that I can use. > > Well, I have been thinking a bit about it. When using music via #..., > the music really needs to be constructed for single use and not used > somewhere else. So it should be feasible to put location data on it > like it is done for $...
I'm interested to document the existence of the $( syntax. There must have been a motivation. Could you point me to the relevant tracker, or mailing list thread, or provide a fresh explanation. Feel free to be brief. > So while one current difference in semantics between music entered via > $... and #... is that the former gets location data (just like \xxx > does) and the latter doesn't, we probably don't do people a favor by > having this additional difference between $... and #... Agreed. > The question is how we actually want to be dealing with point-and-click > and errors occuring from within #{ ... #}. For syntax errors, it does > not seem like anything but the location inside of #{ ... #} itself makes > sense. But the location data for music might make more sense to be > associated with the text origin of the problematic construct. Maybe we > should assign a location only to music that does not yet have one? A syntax error results from a user error in text-land. So link to the definition. For other situations, link to the instantiation, I think. Cheers, Colin.
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user