Relative links broken after cut and pasted to different hierarchy level

[Nick Jackson]

Running Zim (perl) 0.28 from .deb on ubuntu 8.04; Gtk2 version is 1.183.

When you cut and paste a block of text containing a relative link (e.g. [[.Subpage]] ) to another page on a different "hierarchy level" (i.e. if original text was on :Home:Level1:Level2:Page, then was moved to :Home:Level1:Page), those relative links aren't modified to point to the same place they originally did. Thus, in the above example, the link originally would have pointed to :Home:Level1:Level2:Page:Subpage, but afterward points to :Home:Level1:Page:Subpage (a nonexistent page; the original linked page is now "stranded" and inaccessible unless the relative link is manually changed).

This is a pretty straightforward problem--the cut-and-paste simply moves the relative link as-is, without any "awareness" of what the link's actual destination was prior to the move. Note this problem does not exist for pages that are MOVED using Zim's rename page dialog (since it has an "update links" feature).

[Sebastian Audet (smaudet)]

Hi, I believe I may have identified the general area for the fix, however I had a question about where I should implement this, if anyone wants to provide input.

I can either do this inside pageview, however this means I have to implement the sharing mechanism (as well as other machinery) inside pageview, this might not be architecturally sound or wise, or I can create an external object (link-handling.py) which just reads all copy/paste calls and sanitizes them appropriately.

The second approach sounds cleaner but looking at the code it is unclear which route to take - a lot of link handling already seems to occur in various parts of the code, so it might be a good idea to decouple this functionality in future, but at the same time it might cause confusion and also create un-necessary work in re-writing/moving large bits of code functionality.

[Sebastian Audet (smaudet)]

Re the blue print regarding splitting pageview apart, I will go ahead and develop the new functionality in a separate file. This way it becomes easier in future to refactor pageview. A summary of the component follows:

--> cut -->| |
--> copy -->| Link Router | --> modify paste
--> paste-->| |
                                 |
                                 v
| Old Linking Functionality|

If the ASCII art above doesn't render correctly, it may be a monospace font issue.

Link Router will accept cut/copy/paste signals, match them internally, and modify the paste data when appropriate. It may use existing linking functionality found in pageview.

[Sebastian Audet (smaudet)]

One last comment it appears zim is also implemented in perl (why?)?

This fix is applicable to python-zim, and will be developed for python-zim.

If someone could clarify whether perl-zim uses any python or is a straight re-write, let me know.

[Jaap Karssenberg (jaap.karssenberg)]

@sebastian: zim was originally written in perl, than rewritten in python. The perl version is way out of date and unmaintained, so don't bother even looking at it

[Jaap Karssenberg (jaap.karssenberg)]

The solution direction for this bug would be:

1. when copying a parsetree from the pageview to the clipboard resolve all links to their full page paths
2. when pasting a parsetree to the pageview, resolve page links to relative links again

Not sure how this relates to your ascii diagram, but I believe it should be a straight forward patch only touching the internal copy and paste methods.

Regards,

Jaap

[Jaap Karssenberg (jaap.karssenberg)]

P.S. also here please base your work on pyzim-refactor, else I won't be able to merge it later.

[Brian (brian11)]

One thing to consider with the solution Jaap proposed on 2014-02-10 is that copying and pasting a full path would convert them to relative paths. The paste action wouldn't be able to tell the difference between a link that was originally a full path and one that was originally a relative path, so it would convert both of them to relative paths. The links would still work after pasting either one, but the expected behavior of copy and paste is that the pasted information should be the same as what was copied.

I've had problems with links breaking in zim and find that using full paths gives me the fewest problems. I'd probably get frustrated with zim converting my full inks to relative links. On the other hand, maybe fixing this bug would make relative links robust enough that I wouldn't mind using the relative links.

[Jaap Karssenberg (jaap.karssenberg)]

https://github.com/jaap-karssenberg/zim-desktop-wiki/issues/46