> OK. I can see this then, and can adjust for it. That said, however,
> speaking as a potential user of this feature, I find this very
> counterintuitive. I select a bibliography file, choose "Embed" (let's
> say the document is already in embedded status), and now the edits I
> make the file
Bo Peng wrote:
Allow me to answer this critical question first:
Why does it need to happen then? (I understand that this is a high-level
design question.) This seems like something that needs to happen only
when there are certain buffer-level events: Export, saving, etc.
For exampl
Allow me to answer this critical question first:
> Why does it need to happen then? (I understand that this is a high-level
> design question.) This seems like something that needs to happen only
> when there are certain buffer-level events: Export, saving, etc.
For example, when you insert a
Bo Peng wrote:
If you're agreed, I can change the patch this way. The only task is to
write the update() method, really---we could just take over the old
createBibFiles, but that seems like overkill---and for me to undo some
other bits, like registerEmbeddedFile(). OK?
I knew we'd figure th
> If you're agreed, I can change the patch this way. The only task is to
> write the update() method, really---we could just take over the old
> createBibFiles, but that seems like overkill---and for me to undo some
> other bits, like registerEmbeddedFile(). OK?
>
> I knew we'd figure this out
Abdelrazak Younes wrote:
If you want my 2 euro cents Having read superficially this thread, I
think Richard has a point here. I don't think the performance penalty
will be sensible going this way...
Yeah, well nobody asked your view. (There would be a smiley there, but
it's Friday, right?)
I think we're nearing a solution.
You've got two parallel
representations of the parameters, one in the EmbeddedFileList and one
in the InsetCommandParams, and there is simply no way to guarantee that
they are synchronized and therefore that you don't over-write
information that was committ
rgheck wrote:
Bo Peng wrote:
Hi, Richard,
I think most of your problems can be solved in a less-radical way, by
saving relative path, or something like that, so that you can recover
user input.
The attached patch tries to do exactly this. It adds meta_ to
EmbeddedFile and allow InsetBibtex to
> I hate to be a pain the ... about this, but I am morally certain that
> this will not work, at least in the long term. The problem isn't just
> the lack of meta-info. It's the fact that this way of doing things is
> completely contrary to how the InsetCommand hierarchy is supposed to
> work.
Bo Peng wrote:
Hi, Richard,
I think most of your problems can be solved in a less-radical way, by
saving relative path, or something like that, so that you can recover
user input.
The attached patch tries to do exactly this. It adds meta_ to
EmbeddedFile and allow InsetBibtex to add 'biblio' to
10 matches
Mail list logo