bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [Feature request] attach lilypond code in pdf.


From: David Kastrup
Subject: Re: Fwd: [Feature request] attach lilypond code in pdf.
Date: Mon, 09 Jul 2012 16:11:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

-Eluze <address@hidden> writes:

> David Kastrup wrote:
>> 
>> 
>> 
>> What's wrong with using input-file-name ?  This should work for the main
>> input file.  If you need more than that, you can likely work with
>> something like
>> 
>> #(read-hash-extend #\< (lambda (c p) (port-filename p)))
>> 
>> #(display #<)
>> 
>> This will not work before 2.15.twentyish (when I decided that the
>> terrible error messages for Scheme code were not doing anybody a favor,
>> and made port-filename, port-line, and port-column point to sensible
>> locations).
>> 
>> 
>
> this only lacks to be mentioned somewhere in the docs!
>
> great! - are there other such undocumented variables?

The elements of the read-hash-extend thing are all explained in the
Guile manual and just "work as expected" (notwithstanding that this has
not always been the case).  Using a reader extension seems awkward, but
most other stuff is executed at a time when the port is no longer
available.

Of course, pretty much every music expression (and the resulting stream
event) has an 'origin property which you can call
ly:input-file-line-char-column or ly:input_both_locations on (both are
documented), and every music, scheme or event function has a location
parameter carrying the same information.

So it is not like one would be all that dependent on getting this info
from the Scheme reader.  It is not like it would be really hidden.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]