Re: error :GUILE signaled an error for the expression beginning here #

[Thomas Morley]

Am Mo., 12. Juli 2021 um 08:38 Uhr schrieb Jonas Hahnfeld via LilyPond
user discussion <lilypond-user@gnu.org>:
>
> Am Sonntag, dem 11.07.2021 um 22:54 -0700 schrieb Aaron Hill:
> > On 2021-07-11 12:32 pm, ming tsang wrote:
> > > I am confused about this "file information" LSR.
> > > Yesterday, I did a ""file>save as" to a file name to
> > > untitled_LSR_file-info_v2182.ly. This morning I tried to run the
> > > untitled_LSR_file-info_v2182.ly, but I got run error:
> >
> > The code in LSR 197 is not able to properly handle non-ASCII characters
> > in a file path.  Upon review, its use of object->string is mangling the
> > filename.  Also, the entire premise of the snippet is predicated on the
> > false assertion that the command-line only consists of the filename in
> > question.  In practice, there are likely to be many other arguments.  At
> > best, you might be able to rely on the filename being the last argument:
> >
> > %%%%
> > \version "2.18.2"
> >
> > filename = #(last (command-line))
> > \markup { "File Name =" \filename }
> > %%%%
> >
> > However, why mess about with reparsing the command-line arguments in the
> > first place?  LilyPond has already done this for you, so just ask
> > LilyPond for the current filename:
> >
> > %%%%
> > \version "2.20.0" % or newer
> >
> > filename = #(define-scheme-function () ()
> >   (car (ly:input-file-line-char-column (*location*))))
> > \markup { "File Name =" \filename }
> > %%%%
> >
> > You could adapt the above to work on 2.18.2, but calling the function
> > within markup requires some extra sugar:
> >
> > %%%%
> > \version "2.18.2"
> >
> > filename = #(define-scheme-function (parser location) ()
> >   (car (ly:input-file-line-char-column location)))
> > \markup { "File Name =" $#{ \filename #} }
> > %%%%
> >
> > All the more reason to leave 2.18.2 behind and just focus on the newer
> > versions of LilyPond.
>
> Or you could use the (undocumented) \input-file-name, an internal
> variable of the lexer, which seems to be there since "forever".

In the light of this discussion, I modified said LSR-snippet.
Alas, while the code changed, the image is not updated.
https://lsr.di.unimi.it/LSR/Item?id=197
Likely again a LSR-problem ...

Cheers,
  Harm