> I'm fairly convinced that we should not be using the
> EmbeddedFiles stuff to represent the parameters here. That just seems
> like mixing up the wrong things.
Why not? We need to store filenames (I know I need to keep the
original filenames), and the embedding status. Using a EmbeddedFiles
> I'm fairly convinced that we should not be using the
> EmbeddedFiles stuff to represent the parameters here. That just seems
> like mixing up the wrong things.
Why not? We need to store filenames (I know I need to keep the
original filenames), and the embedding status. Using a EmbeddedFiles
ob
Andre Poenitz wrote:
On Thu, Mar 27, 2008 at 04:30:08AM -0400, rgheck wrote:
Attached is a more radical sort of patch, one that disentangles InsetBibtex
from the EmbeddedFiles stuff a bit, while making the logic a lot simpler, I
think. It's at least proof of concept that this kind if disenta
> In a way, but there's no EmbeddedFile object stored there at all. Just
> the old parameter info. We build EmbeddedFile objects when necessary
> mostly so they will tell us about the inzip path and, of course, so we
> can use the copyTo() function. If there were a static
> EmbeddedFile::getIn
Bo Peng wrote:
Comments welcome.
This is pretty radical. You basically have a relative-path version of
EmbeddedFile in InsetBibtex and convert to EmbeddedFile if needed.
In a way, but there's no EmbeddedFile object stored there at all. Just
the old parameter info. We build EmbeddedFi
On Thu, Mar 27, 2008 at 04:30:08AM -0400, rgheck wrote:
>
> Attached is a more radical sort of patch, one that disentangles InsetBibtex
> from the EmbeddedFiles stuff a bit, while making the logic a lot simpler, I
> think. It's at least proof of concept that this kind if disentanglement can
> be
> Comments welcome.
This is pretty radical. You basically have a relative-path version of
EmbeddedFile in InsetBibtex and convert to EmbeddedFile if needed.
How about making EmbeddedFile a standard-alone class that does not
derive from DocFileName? We simply save whatever path, relative or
absol
Attached is a more radical sort of patch, one that disentangles
InsetBibtex from the EmbeddedFiles stuff a bit, while making the logic a
lot simpler, I think. It's at least proof of concept that this kind if
disentanglement can be done. Note that it also disentangles EmbeddedFile
from the bib
On Wed, Mar 26, 2008 at 07:54:03PM -0400, rgheck wrote:
>> Andre sayeth:
>>
>> On Wed, Mar 26, 2008 at 05:29:22PM -0400, rgheck wrote:
>> > [...]
>> > Comments welcome. And see the long FIXME about remaining issues.
>>
>> > +
>> > + docstring embed(getParam("embed"));
>>
>> We use
>>
>>
> I tried using updateParam() after introducing getTeXFile, but that
> didn't work. The problem is that there's no way to tell when you get
> back from EmbeddedFiles what the ORIGINAL path was. Things like: biblio,
> ../biblio, /home/me/biblio, etc, all look the same to EmbeddedFiles at
> that
Andre sayeth:
On Wed, Mar 26, 2008 at 05:29:22PM -0400, rgheck wrote:
> [...]
> Comments welcome. And see the long FIXME about remaining issues.
> +
> + docstring embed(getParam("embed"));
We use
docstring embed = getParam("embed");
[Several occurences]
If you say so, OK. But the
Bo Peng wrote:
Comments welcome. And see the long FIXME about remaining issues.
Why do you remove updateParam and manipulate (in add/remove database
etc) these parameter strings again and again? The original idea was to
change EmbeddedFiles, and write these strings from the file list each
> Comments welcome. And see the long FIXME about remaining issues.
Why do you remove updateParam and manipulate (in add/remove database
etc) these parameter strings again and again? The original idea was to
change EmbeddedFiles, and write these strings from the file list each
time.
Bo
On Wed, Mar 26, 2008 at 05:29:22PM -0400, rgheck wrote:
> [...]
> Comments welcome. And see the long FIXME about remaining issues.
> +
> + docstring embed(getParam("embed"));
We use
docstring embed = getParam("embed");
[Several occurences]
Andre'
The attached patch solves the problem about relative pathnames and
BibTeX files...at least, it solves most of the problem. You can at least
use relative pathnames now, though they won't always work correctly with
the embedding feature (though no worse than before).
I've also fixed up some of
Bo Peng wrote:
Can you explain to me what the embed parameter here is supposed to mean?
I have e.g.
\begin_inset CommandInset bibtex
LatexCommand bibtex
bibfiles "/home/rgheck/files/bibtex/biblio"
embed "./LyX.Embed.Dir.Abs//home/rgheck/files/bibtex/biblio.bib"
options "plain"
The b
> Can you explain to me what the embed parameter here is supposed to mean?
> I have e.g.
> \begin_inset CommandInset bibtex
> LatexCommand bibtex
> bibfiles "/home/rgheck/files/bibtex/biblio"
> embed "./LyX.Embed.Dir.Abs//home/rgheck/files/bibtex/biblio.bib"
> options "plain"
The bib file i
Bo Peng wrote:
I have to say that it seems messy to me that we're effectively storing
two sets of things that have the same significance: params["bibfiles"],
on the one hand, and the embedded file list, on the other. This makes
the logic in InsetBibtex, on which I worked a fair bit and would
> I have to say that it seems messy to me that we're effectively storing
> two sets of things that have the same significance: params["bibfiles"],
> on the one hand, and the embedded file list, on the other. This makes
> the logic in InsetBibtex, on which I worked a fair bit and would have
> t
Stefan Schimanski wrote:
I've traced the problem with citations for a while, and I'm still
kind of puzzled. This has something to do with the fact that
EmbeddedFile objects, since they inherit from FileName, always store
absolute pathnames. But in many of these cases, it seems that the
Embedde
I've traced the problem with citations for a while, and I'm still
kind of puzzled. This has something to do with the fact that
EmbeddedFile objects, since they inherit from FileName, always store
absolute pathnames. But in many of these cases, it seems that the
EmbeddedFile objects actually
Bo Peng wrote:
Is there any progress on this? Is it a problem by design of the new
file handling? Or just a bug? What does "There are a lot of work in
this area." mean? Is anybody actively working on this?
These files are now EmbeddedFiles and their latex output names are
currently wron
22 matches
Mail list logo
