bug-lilypond
[Top][All Lists]
Advanced

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

Re: Changed behaviour of point-and-click


From: Mark Knoop
Subject: Re: Changed behaviour of point-and-click
Date: Thu, 2 Jun 2016 15:11:42 +0100

Sorry for the delayed reply - I've been travelling. See below.

At 18:27 on 17 May 2016, David Kastrup wrote:
>Mark Knoop <address@hidden> writes:
>> Could you indicate a working setup where relative point-and-click
>> links are *not* broken?
>
>They work like other file-relative links in URIs.

To be completely clear, I am of course aware what *should* happen.
However, this doesn't happen with my setup (Evince running in Gnome).
Clicking the link in Evince is identical to running:

xdg-open textedit://file.ly:1:1:1

This has no way of knowing in which directory the PDF is located, and is
run by default in $HOME.

Please, could somebody describe a setup (specific os, desktop,
pdf-reader) where relative links DO work? Urs, do relative links work
for you?

At 05:47 on 17 May 2016, Urs Liska wrote:
>It has been brought up more than once that having full paths in the
>point-and-click links *might* be considered a security issue. And much
>more important, having relative point-and-click links would make the
>files more portable: if you send someone a zip file with .ly and .pdf
>files in it relative links would work right out-of-the-box, without
>prior compilation. Or if you move/rename a working tree on your
>computer the point-and-click-links wouldn't be broken anymore.

What is the point of sending a .ly and a .pdf? Surely the point of
sending the source is that you don't need to send the pdf.

>On the other hand, if a recompilation is required to make
>point-and-click links work, what are they useful for, anyway?

Links are useful during the edit-compile-edit cycle to jump to specific
locations in the source from the compiled pdf.

>In short: I suggest not to revert the above patch but make the
>behaviour configurable through a command line switch.
>
>What do you think:
>- revert the patch
>- keep the patch
>- keep the patch, add configuration option and make relative links
>default
>- keep the patch, add configuration option and make absolute links
>default ?

The patch should certainly be reverted not least because the description
is incorrect. If people have a use for relative links then redo a
corrected patch and add a configuration option. Links have always been
absolute in the past and so should be the default.

--
Mark Knoop



reply via email to

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