Re: 2.19.x Point and click references
On Sun, Apr 27, 2014 at 11:04 PM, David Kastrup d...@gnu.org wrote:
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.
You're absolutely right. I was misremembering. I should have tried this.
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.
This is interesting. I changed the 'location' argument's name and it
still showed correct error locations. Also the point and click
locations are correct. So it seems a workaround is to do this
renaming. Thanks, this is useful (though somewhat surprising
behavior).
Also I think this explains why I thought it worked in the past. I
think I was using a pure scheme function in between the score
generation and the call from lilypond. So it just happened to work.
-Jay
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.19.x Point and click references
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
2.19.x Point and click references
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. 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.
-Jay
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
