Bo Peng wrote:
Well I think I do now but you're right, let's postpone this discussion until
you get some more temper :-)
Sorry for resuming (again!) the discussion.
I was in a pretty good mode until you accused me of not listening to
Richard carefully, which reminded me my frustrations in
>> No. If this is the case, Richard should have put it to the wiki.
>
> I didn't read all the messages but I am pretty sure Richard said exactly
> what I am saying, JMarc AFAIR.
You may be right, but Richard did not put it in any of his summaries,
nor did he put it in the wiki. If he had this idea
Bo Peng wrote:
Your agument is amazingly similar to Richard's "A world's simplest
script can solve this". I will not argue here but I would remind you
that LyX is used by many users, many of whom do not know how to write
a script, or know such an advanced feature of svn. The KISS idea
should be a
>> Your agument is amazingly similar to Richard's "A world's simplest
>> script can solve this". I will not argue here but I would remind you
>> that LyX is used by many users, many of whom do not know how to write
>> a script, or know such an advanced feature of svn. The KISS idea
>> should be app
Bo Peng wrote:
Second, even if you (or someone else) insist on this issue, we are talking
about diff friendly here, not svn. Svn doesn't really care if the file is
text or binary. FYI you can configure svn to use any helper application
besides diff. We could for example create a python script tha
>> of my approach is
>> that there is no bundled mode, and there is no unbundle. The file is
>> continued to be svn friendly, and nobody would svn a compressed
>> bundle.
>
> OK, replace 'bundled' with 'embedded' and you get the same result: there is
> no need to be svn friendly, I mean at all.
I
Bo Peng wrote:
I really don't understand why you insist on putting a bundled .lyx file into
an SCM (svn). Either you use an scm or you use a bundled file, not both. If
you use an SCM and receive a bundled file, unbundle it and put it in an SCM,
as simple as that. There is absolutely no need to be
On Wed, May 21, 2008 at 11:54 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
>> It seems as if we could probably even merge the diff if different sub
>> files were changes. Still seems unsatisfying, as most likely in both
>> zip/ar files the base .lyx file would have been changed.
>
> Never tried this. Thi
> I really don't understand why you insist on putting a bundled .lyx file into
> an SCM (svn). Either you use an scm or you use a bundled file, not both. If
> you use an SCM and receive a bundled file, unbundle it and put it in an SCM,
> as simple as that. There is absolutely no need to be SCM frie
> Well diff -a somewhat informative, although very messy. I can clean
> the diff of two zip -0 files as follows:
No one will actually use zip -0. When compression is used, it is used
to reduce file sizes.
> $ diff -a shfiles{,2}.zip | strings | grep '^[<>]'
> < top -n 1 | grep Cpu.s | grep
John McCabe-Dansted wrote:
On Wed, May 21, 2008 at 11:05 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
According to this,
http://svn.haxx.se/users/archive-2008-03/0376.shtml
svn handles binary diffs efficiently. I suspect that it would likewise
handle zip -0 even more sensibly. Merging diffs may s
On Wed, May 21, 2008 at 11:05 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
>> According to this,
>> http://svn.haxx.se/users/archive-2008-03/0376.shtml
>> svn handles binary diffs efficiently. I suspect that it would likewise
>> handle zip -0 even more sensibly. Merging diffs may still be a problem.
>
> According to this,
> http://svn.haxx.se/users/archive-2008-03/0376.shtml
> svn handles binary diffs efficiently. I suspect that it would likewise
> handle zip -0 even more sensibly. Merging diffs may still be a problem.
I think the issue here is not only about efficiency, but also about
usabil
On Wed, May 14, 2008 at 11:57 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
> 2) The plain text file is more svn friendly, easier to work with for
> tasks other than extracting external files. I do not really care about
> index-generation applications. I also pointed out that this format is
> more natura
> It is nor a shell extension, just using a zip library to extract only
> one file from the list.
Practically, I do not see any advantage of doing that. OK. We can
extract only filename.lyx to $TEMP_DIR to open it, but to open it, we
'need' an embedded layout file. Then graphic loaders 'need' a f
"Bo Peng" <[EMAIL PROTECTED]> writes:
> Thanks. I see the point now. By using some sort of shell extension,
> LyX does not have to extract all files to open some of them. I guess
> this is what you were trying to achieve with your directory-in-a-file
> idea.
It is nor a shell extension, just usin
On Tue, May 20, 2008 at 5:01 PM, Jean-Marc Lasgouttes
<[EMAIL PROTECTED]> wrote:
> "Bo Peng" <[EMAIL PROTECTED]> writes:
>
>> I do not quite get it. Are we talking about base64 vs. zip? When you
>> open both types of files, you need to extract embedded files first.
>> After that, all the operations
"Bo Peng" <[EMAIL PROTECTED]> writes:
> I do not quite get it. Are we talking about base64 vs. zip? When you
> open both types of files, you need to extract embedded files first.
> After that, all the operations are the same. If you are comparing
> between the base64 bundle, and the filename + dir
> Sure but I think you miss two points:
> - LyX does not read these files most of the time thanks to the converter
> cache; and if it does it reads then asynchronously after the .lyx file is
> loaded on screen. In effect this means that the user sees a much faster
> loading time.
> - most of the ti
Andre Poenitz wrote:
On Tue, May 20, 2008 at 10:00:56AM +0200, Abdelrazak Younes wrote:
But Base64 blobs have the disctinct inconvenient that LyX will have to read
all embedded files itself. This will kill the file loading time if we abuse
such method. OK, we could organize the .lyx file so
On Tue, May 20, 2008 at 10:06:25AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
>> Base64 blobs have the distict advantage of retaining the possibility to
>> edit the .lyx file in a text editor - which I used to do quite often...
>>
> By the way, I know you are a shell guy but modern d
On Tue, May 20, 2008 at 10:00:56AM +0200, Abdelrazak Younes wrote:
> But Base64 blobs have the disctinct inconvenient that LyX will have to read
> all embedded files itself. This will kill the file loading time if we abuse
> such method. OK, we could organize the .lyx file so that all blobs are a
Abdelrazak Younes wrote:
Andre Poenitz wrote:
Base64 blobs have the distict advantage of retaining the possibility to
edit the .lyx file in a text editor - which I used to do quite often...
But Base64 blobs have the disctinct inconvenient that LyX will have to
read all embedded files itself.
Andre Poenitz wrote:
Base64 blobs have the distict advantage of retaining the possibility to
edit the .lyx file in a text editor - which I used to do quite often...
By the way, I know you are a shell guy but modern desktops allow in-zip
file editing. This leverage a bit the cited advantage. O
Andre Poenitz wrote:
On Wed, May 14, 2008 at 06:11:17PM -0400, Richard Heck wrote:
(ii) Bo packs everything into the LyX file using base64 encoding; I put the
files in a subdirectory and then wrap the whole bundle into a zip file.
But that's just a confusion, and there's no real difference
> Speaking from a former life: In almost all cases I would have liked to
> have fully embedded (i.e. "copied") graphics, drawings, code snippets
> even if I used them in multiple .lyx files. A noteworthy exception would
> have been the .bib files that continued to receive minor updates (mostly
> sp
On Mon, May 19, 2008 at 08:55:00AM -0400, rgheck wrote:
> Of course. But the question is whether having the feature is worth the
> clutter, especially if no-one will actually use the flexibility involved
> with individual embedding. I still don't see the use case that requires
> this.
Speaking
On Wed, May 14, 2008 at 06:11:17PM -0400, Richard Heck wrote:
> (ii) Bo packs everything into the LyX file using base64 encoding; I put the
> files in a subdirectory and then wrap the whole bundle into a zip file.
>
> But that's just a confusion, and there's no real difference here. First: I
> OP
Andre Poenitz wrote:
So there's really only one thing to discuss. That said, I'll try to clear
up some confusions below.
Approach one: individual embedding.
1) Each and every external file can be embedded individually, using an
embed checkbox in related inset dialogs.
2) The embedded file
rgheck wrote:
Bo Peng wrote:
When I use a computer program to generate a figure figure.png, and
insert it to a list file, do you expect me to change my script and let
it update filename.lyxdir/figures/blah.png? This is unacceptable
especially when there is no way to know in advance what the file
Bo Peng wrote:
3) The code needed for this approach is much more complex than the code
needed for the other approach.
I do not take this one. Have you ever read my patch? The changes to
InsetGraphics are only a few lines.
Yes, I have. Your code is more complex, because you have to mana
Bo Peng wrote:
There's no difference between the approaches on this point. On my treatment,
the files are already "unbundled" in filename.lyxdir/, and you can do with
them as you like.
I need to go but,
I have asked you before whether or not you expect users to manipulate
files inside fil
On Wed, May 14, 2008 at 6:01 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:
>> Please, there is no 'free write back to tree' stuff ...
>
> then i haven't been able to get reasonable image of proposals from
> your summary.
Well, you have not told me where you got this 'free write back to
tree' feeling.
> Please, there is no 'free write back to tree' stuff ...
then i haven't been able to get reasonable image of proposals from
your summary.
and frankly from both answers i feel you both haven't been able to
understand each other yet.
maybe it would be better idea to setup wiki page where each of
>
> There's no difference between the approaches on this point. On my treatment,
> the files are already "unbundled" in filename.lyxdir/, and you can do with
> them as you like.
I need to go but,
I have asked you before whether or not you expect users to manipulate
files inside filename.lyxdir di
> 3) The code needed for this approach is much more complex than the code
> needed for the other approach.
I do not take this one. Have you ever read my patch? The changes to
InsetGraphics are only a few lines.
> It gets wrapped to filename.lyz, and the tool used to wrap it is an
> implementation
> nono, i mean the extension of the resulting embeded (or bundled) file.
> currently the name will filename.lyx (right?) which i'm opposed and will later
> flame on, no matter which proposal is going to be used :)
The filename in my approach is .lyx because there is no bundled mode,
even after you
Bo,
thanks for your responses.
> > - was there some conclusion about filename extension? if there are going
> > to be
> > any tricks with copying or moving .lyx file itself i smell thousand and
> > one
> > problems of rewrites, bad deletions on user side etc. i think that some
> > .lyz
>
Bo Peng wrote:
- i don't like the 'extract all embed' feature in concept1. if some chaotic
co-author on the other side embed files from different paths on filesystem
i will be _very_ annoyed by lyx disseminate these file on hundred and one
locations on my filesystem. we shouldn't allow thi
Bo Peng wrote:
Dear all,
Two approaches to embed or bundle external files have been presented
in the 'alternative to individual embedding?' thread. If you are
interested, but did not have time to follow the heated discussions,
here is a summary.
Here's my summary.
As far as I can see, the
> This has been debated. Using the second approach, because lyx has to
> work on the unbundled .lyx file, it is difficult to restore relative
> locations of extracted files. This is why Richard chose not to
> unbundle files to their original locations. Unbundling will be an
> export feature t
> the first thing is whether you both agree on this summary :)
> maybe Richard would like to change some points :)
They are basically 'facts' extracted from the debate. Of course
Richard can correct me if I were wrong.
> - i don't like the 'extract all embed' feature in concept1. if some chaot
Bo Peng wrote:
> I can continue but I think these are enough reasons not to adopt the
> second approach, especially when the first approach does not have any
> major problem.
the first thing is whether you both agree on this summary :)
maybe Richard would like to change some points :)
some note
43 matches
Mail list logo
