Changed behaviour of point-and-click

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Changed behaviour of point-and-click

Urs Liska
As reported by Mark Knoop in
http://lists.gnu.org/archive/html/bug-lilypond/2016-05/msg00005.html
this commit

commit f30a8189adbbeefa2103e2c2e194040f66bc2291
Author: Urs Liska <[hidden email]>
Date:   Tue Jan 19 10:52:33 2016 +0100

    #4747: Remove (all) uses of is-absolute?
   
    The check for absolute paths in  in output-ps.scm
    and -svg.scm is unnecessary because
    (car ly:input-file-line-char-column a-location)
    always returns an absolute, slashified path
   
    Now is-absolute? is not used anymore by LilyPond itself.


has the side-effect of affecting the point-and-click links. If the file
path passed to LilyPond is relative the point-and-click links are
relative as well.

Of course this is an unwanted side-effect of my patch, but I would like
to discuss if this is a feature rather than a bug.

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.
On the other hand, if a recompilation is required to make
point-and-click links work, what are they useful for, anyway?

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
?

Mark, can you give us a reason why you consider relative point-and-click
links "broken"?

Best
Urs

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of point-and-click

David Kastrup
Urs Liska <[hidden email]> writes:

> As reported by Mark Knoop in
> http://lists.gnu.org/archive/html/bug-lilypond/2016-05/msg00005.html
> this commit
>
> commit f30a8189adbbeefa2103e2c2e194040f66bc2291
> Author: Urs Liska <[hidden email]>
> Date:   Tue Jan 19 10:52:33 2016 +0100
>
>     #4747: Remove (all) uses of is-absolute?
>    
>     The check for absolute paths in  in output-ps.scm
>     and -svg.scm is unnecessary because
>     (car ly:input-file-line-char-column a-location)
>     always returns an absolute, slashified path
>    
>     Now is-absolute? is not used anymore by LilyPond itself.
>
>
> has the side-effect of affecting the point-and-click links. If the file
> path passed to LilyPond is relative the point-and-click links are
> relative as well.
>
> Of course this is an unwanted side-effect of my patch, but I would like
> to discuss if this is a feature rather than a bug.

If it's a feature, the links still need to point to the source
regardless of where LilyPond places the PDF, even if sources are found
through some search path or an include relative from the starting
directory or the including file.  If the PDF path is specified
absolutely, no relative links should be produced: only if the original
connection between source and PDF is relative, the result should be
relative.

Doing this correctly is not easy.  It very likely won't happen by
accident.

--
David Kastrup

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of point-and-click

Mark Knoop-4
In reply to this post by Urs Liska
At 05:47 on 17 May 2016, Urs Liska wrote:
>Mark, can you give us a reason why you consider relative
>point-and-click links "broken"?

I am unaware of any way for the pdf viewer, or the whatever handles the
textedit url, to know what the link is relative to. Correct me if I am
wrong on this.

--
Mark Knoop

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of point-and-click

Urs Liska


Am 17.05.2016 um 14:30 schrieb Mark Knoop:
> At 05:47 on 17 May 2016, Urs Liska wrote:
>> Mark, can you give us a reason why you consider relative
>> point-and-click links "broken"?
> I am unaware of any way for the pdf viewer, or the whatever handles the
> textedit url, to know what the link is relative to. Correct me if I am
> wrong on this.

I think the links should be relative to the location of the PDF. But as
David pointed out it's less trivial than one might think to determine
what that properly is always.

>


_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of point-and-click

Mark Knoop-4
At 10:32 on 17 May 2016, Urs Liska wrote:

>Am 17.05.2016 um 14:30 schrieb Mark Knoop:
>> At 05:47 on 17 May 2016, Urs Liska wrote:  
>>> Mark, can you give us a reason why you consider relative
>>> point-and-click links "broken"?  
>> I am unaware of any way for the pdf viewer, or the whatever handles
>> the textedit url, to know what the link is relative to. Correct me
>> if I am wrong on this.  
>
>I think the links should be relative to the location of the PDF. But as
>David pointed out it's less trivial than one might think to determine
>what that properly is always.

Indeed, it's not trivial for lilypond to know that, but that is not my
point.

Even if the links *are* valid, relative to the location of the pdf, do
you then expect the pdf viewer to convert them to absolute links?
Evince certainly doesn't do that. Maybe other pdf viewers do.

Or instead, if the relative link is passed to the url-handler (usually
via a desktop environment such as Gnome, Windows, etc), how does that
handler know what the link is relative to? i.e.: what file should

lilypond-invoke-editor textedit://file.ly:1:2:3

open?

Could you indicate a working setup where relative point-and-click links
are *not* broken?

--
Mark Knoop

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of point-and-click

David Kastrup
Mark Knoop <[hidden email]> writes:

> At 10:32 on 17 May 2016, Urs Liska wrote:
>>Am 17.05.2016 um 14:30 schrieb Mark Knoop:
>>> At 05:47 on 17 May 2016, Urs Liska wrote:  
>>>> Mark, can you give us a reason why you consider relative
>>>> point-and-click links "broken"?  
>>> I am unaware of any way for the pdf viewer, or the whatever handles
>>> the textedit url, to know what the link is relative to. Correct me
>>> if I am wrong on this.  
>>
>>I think the links should be relative to the location of the PDF. But as
>>David pointed out it's less trivial than one might think to determine
>>what that properly is always.
>
> Indeed, it's not trivial for lilypond to know that, but that is not my
> point.
>
> Even if the links *are* valid, relative to the location of the pdf, do
> you then expect the pdf viewer to convert them to absolute links?

By starting the respective URI handler with the cwd set to the directory
the PDF is in.

> Or instead, if the relative link is passed to the url-handler (usually
> via a desktop environment such as Gnome, Windows, etc), how does that
> handler know what the link is relative to? i.e.: what file should
>
> lilypond-invoke-editor textedit://file.ly:1:2:3
>
> open?

file.ly as seen from the current work directory with which
lilypond-invoke-editor is started.

> Could you indicate a working setup where relative point-and-click
> links are *not* broken?

They work like other file-relative links in URIs.

--
David Kastrup

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

Re: Changed behaviour of point-and-click

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

At 18:27 on 17 May 2016, David Kastrup wrote:
>Mark Knoop <[hidden email]> 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

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond