On Thursday 03 April 2008 19:28:21 Bo Peng wrote: > > > If I accept that much, I still have to copy files around and modify > > > each and every copies if it needs to be modified. This is exactly the > > > thing I would like to avoid. > > > > This goal is independent of the next sentence. > > Not exactly.
Yes in the sense that sharing can be done without the reference to the initial file path. You are insisting on this feature although there are no known examples of this behaviour. > I want to share the same files across different lyx > documents, so I do not want to keep local copies. The link solution > was suggested but it does not really work. As I said it is extremely easy to create a file text like this: embbeded1 /path/to/embbeded1 embbeded2 /path/to/embbeded2 embbeded3 /path/to/embbeded3 embbeded4 /path/to/embbeded4 And since the lyx bundle is a zip archive to compare the file content between embbeded1 and /path/to/embbeded1. I have programs in python to walk inside R packages, that usually are tar.gz packages, that extracts files, parse other files and so on in very few lines. This solution works. And it keeps the data where where it belongs. > > > Basically, I would like to share the same > > > files across different lyx documents. > > > > I think that we all agree here. > > Then you have to agree with the need to access out of tree files. If we included them in the bundle they are no longer out of tree files. > > > If I do accept that much, we still differ by the embed-editing mode. > > My implementation has an embed-editing mode. That is basically the > word/ooffice way of handling embedded objects. Right now, this is the > mode to use when an embedded file is opened, until a user unbundle the > file. Richard's solution always unbundles, so there is no such mode. In a sense we already do this when we transfer the files to the temporary directory to compile the lyx file. And this is what I suggest as well. > Cheers, > Bo -- José Abílio
