Jay Anderson <horndud...@gmail.com> writes: > point_and_click_2.19.ly: > ============================= > \version "2.19.5" > > makeScore = > #(define-void-function (parser location) () > (let ((score > #{ > \score > { > \new Staff { \include "00.ily" } > } > #})) > (add-score parser score))) > > \makeScore > ============================= > > 00.ily: > ============================= > \relative c' { c4 c c c | } > ============================= > > When compiling the above files the point-and-click links do not point > to the '00.ily' file. Instead they all point to the final line of > 'point_and_click_2.19.ly'. In 2.18 this worked correctly.
Without actually testing it, I consider this unlikely. It would appear to be <URL:http://code.google.com/p/lilypond/issues/detail?id=3153>, namely changed in 2.17.13. While it's conceivable that \include handling has been changed independently, this does not really change the rationale of the change, namely pointing out _which_ invocation of a function is responsible for some input. Which is particularly important for trivially correct functions called hundreds of times. You really don't want to have point-and-click point to the function definition then. > it's also worth noting that if you introduce an error to 00.ily the > errors reported do use the correct filename and line number. Yes, that's what one wants for debugging. There is a somewhat funny way to change this behavior: just use an argument name different from "location" for the location argument, and #{...#} will not be able to pick it up for passing it to point-and-click. -- David Kastrup _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond