Equation and image files should be copied when the object is copied in the text

[James]

Zim-0.27-1.fc10.noarch

If I copy and paste an equation within a page, modifying one modifies its parent and siblings. This can be annoying if I am trying to write several similar equations. Please make each copy of the equation a new object. This could also solve the (more frustrating) problem of equations disappearing after copying to other pages, since the resources (.png and .tex files) are not available for those pages.

Thanks!

[dotancohen (dotancohen)]

I can confirm this issue in Zim 0.27. I have seen this issue mentioned before (mailing list maybe), and I thought this was a dupe but could not find a previous bug. So at least three people are having this issue.

[Jaap Karssenberg (jaap.karssenberg)]

Needs a little more input on when / how to do this. I can also imagine a valid use case where you want to have the same equation in multiple places and keep the link instead of repeating them.

There is a similar case for images. If I copy an image to a different page, right click it to open with gimp, edit and save, what should be the behavior ? Currently both pages link to the same page and will show the editing.

Maybe, when you click edit we should detect that it is used in multiple pages and popup asking whether you want to edit all occurences or just this one. (This effectively implements a kind of copy-on-write scheme.) Problem there is that you do not know if the external program that is started is an editor or not.

Now the behavior for equations may be different, but since the implementation between equations and images is very similar I would like a general strategy on how to deal with external objects in copy operations.

Input is welcome.

[dotancohen (dotancohen)]

> Needs a little more input on when / how to do this.

As the OP mentioned, just copy the .tex and .png files.

> I can also
> imagine a valid use case where you want to have the same equation
> in multiple places and keep the link instead of repeating them.

I can imagine this case as well, but the bug should not be confused with a generic soft link feature request. In order to implement the feature you mention, a section of text (not necessarily a latex equation) could be selected then soft-linked (shown in a second place, where updating one will update the other). If you want I will file a feature request.

> There is a similar case for images. If I copy an image to a different
> page, right click it to open with gimp, edit and save, what should
> be the behavior?

The behaviour should be that the second image is edited, and the first left alone. In a file manager, when copying an image any edit made to the copy does not affect the original. Otherwise, you have a soft link and not a copy.

> Currently both pages link to the same page and will show the editing.

That is wrong, if the user wants that they he should have soft-linked, not copied.

> Maybe, when you click edit we should detect that it is used in multiple
> pages and popup asking whether you want to edit all occurences or just
> this one. (This effectively implements a kind of copy-on-write scheme.)
> Problem there is that you do not know if the external program that is
> started is an editor or not.

Again, soft linking is the logical answer to this.

[Jaap Karssenberg (jaap.karssenberg)]

If you put it like that I have to agree.

I would then propose to do this for all "embedded" object (i.e. images and equations). Clearly for external files that are linked we should copy the link. Not sure for attachments that are linked (e.g. a pdf attached to a page) do we copy there or just preserve the link ?

I think this ties in to another bug about management of attachments.

[crazy2be (crazy1be)]

I think the bigger issue here is that the current behavior breaks images and equations when they are copied between pages- something which should, in my opinion, be considered a major and high-priority bug. Prior to being aware of this bug, I cut some text (including equations) from one page of my notebook to another, saw that everything appeared to copy correctly, switched pages, and was astonished to find that my equations had disappeared when I switched back. The current behavior makes it impossible to organize notebooks by moving content between pages when those pages include equations.

[crazy2be (crazy1be)]

Here's a patch that corrects this issue. I'm not entirely happy with it, because it's very "raw"- nothing is abstracted through a store object. However, I'm unfamiliar with your store API and it's intended use, and such unsure of the best way to solve this problem using a clean API. Please provide me with any feedback you have, including any advice on how to abstract this through the store API.

[leoluk (leoluk)]

I'd suggest to differentiate between attachments and inline objects.

The source for embedded objects like equations should actually be embedded in the page (like WikidPad does), with the pictures being generated on-the-fly.

[Jaap Karssenberg (jaap.karssenberg)]

On Tue, Oct 23, 2012 at 2:30 AM, leoluk <email address hidden> wrote:
> I'd suggest to differentiate between attachments and inline objects.
>
> The source for embedded objects like equations should actually be
> embedded in the page (like WikidPad does), with the pictures being
> generated on-the-fly.

This is the approach being worked at in the pyzim-next branch.

-- Jaap

[Mallard (mallardzoom)]

I just got burnt by this bug. I like to write my notes quite freely and then prune, edit and reorganise afterwards by moving pages, creating sub pages, copy and pasting etc... Well after entering a couple of months worth of maths notes into my main wiki and then reordering the pages into the right sections I've been left with swathes of blank latex equations that I don't have the heart to reenter, especially as I don't want to be 'locked' into a specific page hierarchy (reorganising my notes is one of the main reasons I like to use zim rather than paper).

So I was wondering, is this still a low priority bug, any eta on when it will be fixed and what are the best workarounds right now?

[Jaap Karssenberg (jaap.karssenberg)]

Sorry to hear how you got burnt. Simply didn't think about that use case
I'm afraid. Will push it up in prio on my list, but will take some time to
get solved.

Regards,

Jaap

On Sat, Sep 6, 2014 at 9:54 AM, Mallard <email address hidden> wrote:

> I just got burnt by this bug. I like to write my notes quite freely and
> then prune, edit and reorganise afterwards by moving pages, creating sub
> pages, copy and pasting etc... Well after entering a couple of months
> worth of maths notes into my main wiki and then reordering the pages
> into the right sections I've been left with swathes of blank latex
> equations that I don't have the heart to reenter, especially as I don't
> want to be 'locked' into a specific page hierarchy (reorganising my
> notes is one of the main reasons I like to use zim rather than paper).
>
> So I was wondering, is this still a low priority bug, any eta on when it
> will be fixed and what are the best workarounds right now?
>
> --
> You received this bug notification because you are subscribed to Zim.
> https://bugs.launchpad.net/bugs/330320
>
> Title:
> Equation and image files should be copied when the object is copied in
> the text
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/zim/+bug/330320/+subscriptions
>

[LOVEJesus (juan+++)]

Happy to hear that you will push this bug up in your prio list. As Mallard said, this bug is really a hindrance when reorganising the notes.
By the way, thanks again for this amazing tool: zim. My favourite notes application.

Blessings,
Juan

[Jaap Karssenberg (jaap.karssenberg)]

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

[Kaspar Schwarzenbach (schwaba)]

ZIM 0.65
I'm happy to read you having pushed this issue to medium: I very much Mallard, about the importance of the ability to move pages around.
Is there a patch available? I don't quite understand the information given under .../zim-desktop-wiki/issue/45
Thanks for your otherwise great program!
Kaspar