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 file that should be embedded, it should be immediately copied to temppath(), and further modification to that file should not change the embedded version. This may not be critical to normal disk files, but you can imagine pasting from clipboard (either from lyx or outside), where the source may not exist afterwards. This is easily the case when you copy an embedded inset to another buffer, and close the original buffer. > > If, in some case as you mentioned, some developer > > change params without checking EmbeddedFile, lyx may crash due to > > inconsistent embedded file. THAT IS TO SAY, you can NOT change params > > independently, so what is the point of separating them? > > > If the problem is that bad, then the solution you're suggesting would > require us to reimplement the whole parameter-setting mechanism, it > seems to me. Otherwise, you are asking for problems down the road. If we > have to go that way, we can, of course, but it seems very messy to me. > And I don't see why the InsetCommand structure should change just to > accommodate the EmbeddedFile feature. EmbeddedFile constains *run-time* information (file location, enabled etc) whereas params contains only static information. I agree that the current parameter-setting mechanism is not optimal, but it is too costly to change it now. > OK, that would need sorting out. But let's come back to it if necessary. > Part of why I'm puzzled is that I don't see where this is happening in > the existing code. I have to run, but ... > This destroys the old EFList and creates a new one from scratch every > time the inset is modified. I am too lazy to really 'update' the list here, so I just create one. The false enable call should be used here. > And as far as the true/false issue goes, why don't I have that problem > at line 771? Answer: Because you do the true call in GuiBibtex. But > that's insufficient, because this doesn't have to be called from there. > LFUNs can be called in lots of ways, including from the mini-buffer. So > you really need true here. Or else, what seems a better solution, don't > destroy bibfiles_ and recreate it. Just make the new ones and do the > true call for those. But I can do that as well, right? Your GuiBlah/InsetBlah argument makes sense and I do not quite remember why I moved the relevant code to GuiBlah... Anyway, my implementation can be buggy so let us figure out the overall idea, then fix the code together. I can see that you understand the embedding code quite well now. :-) Really have to run. Cheers, Bo
