>> > I recommend to look at the actual repository, not a mirror; here
>> > is a link to the current version in the 'master' branch.
>
> Surely the appropriate source to view is that which is being run.
While this is true in general, Gabriel was interested in the latest
development version, IIRC, mainly to find out whether there were
recent changes in this particular file.
>> It might be worth linking to these GitLab links, somehow, in the
>> official documentation?
After some thinking, I believe this is much trickier than expected.
As David points out, a link in the documentation to a file in the git
repository should exactly match the documented version – this is
especially true for the development versions, where anything can
change any time. It would be thus necessary to update all git
repository references in the documentation to use the right version
tag, which is only set at the time a new release is made.
Here is a sketch of a possible solution.
* Wrap all files of interest into a newly defined macro in the Texinfo
source files of the documentation. For example, replace
`@file{titling-init.ly}` with `@gitfile{ly, titling-init.ly}` (the
first argument gives the directory, the second the file name – you
don't want to show a full path every time while talking about a
file).
BTW, this must be done sparsely, because the PDF documentation
always shows the complete link.
* Write a script that walks over the generated documentation in the
build directory to replace
@gitfile{ly, titling-init.ly}
with
@uref{https://gitlab.com/lilypond/lilypond/-/blob/v2.25.33/ly/titling-init.ly,
@file{titling-init.ly}}
* Integrate the script into the build system so that it gets called by
`make dist` and friends.
IF we decide this is a good idea (I'm not sure), a volunteer would be
necessary to work on that since I don't have enough spare time, sorry.
> I think it would be better to make it simple to find the location of
> the user's code.
What do you envision to do that?
Werner
