Re: InsetBibtex and InsetCommandParams
Please see my other message. What Andre envisages is rolling InsetCommandParams into the insets. That could be done, of course, but there are at least some reasons not to do it. The reasons not to do it are the same as the reasons to have InsetGraphicsParams be separate from InsetGraphics, so this has nothing to do with ICP as such. Another option, perhaps the one you have in mind, is to ditch ICP altogether here and do for InsetBibtex what is presently done for InsetGraphics and InsetExternal, namely, to give them there own parameter class built from scratch. But I can see no good reason to do that. And at present, there is massive code duplication in those two classes. I don't see why we should add to the chaos. I have had limited experience with InsetCommand, all of them were pretty negative. In the case of InsetBibtex, making a comma separated string as the core structure, and parsing it each time looks really awkward to me. If this was acceptable before the embedding age, it is not acceptable when two sets of data structure are used to represent basically the same information and we have to keep them synced. I would not hesitate at all, to build EmbeddedFIleList when the inset is loaded, manipulate it, and convert it to the latex string when the inset is saved. This has been done for InsetGraphicsParams where EmbeddedFile is used, and I think this is, IMHO, the right thing to do. Of course I also respect your chaos judgment. Cheers, Bo
Re: InsetBibtex and InsetCommandParams
Bo Peng wrote: Please see my other message. What Andre envisages is rolling InsetCommandParams into the insets. That could be done, of course, but there are at least some reasons not to do it. The reasons not to do it are the same as the reasons to have InsetGraphicsParams be separate from InsetGraphics, so this has nothing to do with ICP as such. Another option, perhaps the one you have in mind, is to ditch ICP altogether here and do for InsetBibtex what is presently done for InsetGraphics and InsetExternal, namely, to give them there own parameter class built from scratch. But I can see no good reason to do that. And at present, there is massive code duplication in those two classes. I don't see why we should add to the chaos. I have had limited experience with InsetCommand, all of them were pretty negative. In the case of InsetBibtex, making a comma separated string as the core structure, and parsing it each time looks really awkward to me. I agree. The alternative I suggested would avoid this. All of this is a remnant of a much older system, according to which an inset's data was stored simply in the form of a LaTeX command string. I'd rather we stored lists like this: bibfile biblio1 bibfile biblio2 This seems especially important with the embed parameter. It's unusual, but /home/heck,rg/biblio.bib is a perfectly valid filename. It would break our system right now. If this was acceptable before the embedding age, it is not acceptable when two sets of data structure are used to represent basically the same information and we have to keep them synced. I would not hesitate at all, to build EmbeddedFIleList when the inset is loaded, manipulate it, and convert it to the latex string when the inset is saved. This has been done for InsetGraphicsParams where EmbeddedFile is used, and I think this is, IMHO, the right thing to do. I haven't looked enough at IGP to know whether there are potential problems there like the ones we have been discussing here. If so, then so; if not, not. What I do know, as I've said, is that there is massive duplication of code. rh
Re: InsetBibtex and InsetCommandParams
José Matos wrote: On Wednesday 02 April 2008 18:25:11 Bo Peng wrote: Of course I also respect your chaos judgment. Come on this does not help any discussion. :-( Actually, that was meant seriously and nicely. I'd said that there'd be too much chaos if we did something, and Bo was saying he respected that judgment. rh
Re: InsetBibtex and InsetCommandParams
On Wednesday 02 April 2008 18:25:11 Bo Peng wrote: Of course I also respect your chaos judgment. Come on this does not help any discussion. :-( Cheers, Bo -- José Abílio
Re: InsetBibtex and InsetCommandParams
> Please see my other message. What Andre envisages is rolling > InsetCommandParams into the insets. That could be done, of course, but there > are at least some reasons not to do it. The reasons not to do it are the > same as the reasons to have InsetGraphicsParams be separate from > InsetGraphics, so this has nothing to do with ICP as such. > > Another option, perhaps the one you have in mind, is to ditch ICP > altogether here and do for InsetBibtex what is presently done for > InsetGraphics and InsetExternal, namely, to give them there own parameter > class built from scratch. But I can see no good reason to do that. And at > present, there is massive code duplication in those two classes. I don't see > why we should add to the chaos. I have had limited experience with InsetCommand, all of them were pretty negative. In the case of InsetBibtex, making a comma separated string as the core structure, and parsing it each time looks really awkward to me. If this was acceptable before the embedding age, it is not acceptable when two sets of data structure are used to represent basically the same information and we have to keep them synced. I would not hesitate at all, to build EmbeddedFIleList when the inset is loaded, manipulate it, and convert it to the latex string when the inset is saved. This has been done for InsetGraphicsParams where EmbeddedFile is used, and I think this is, IMHO, the right thing to do. Of course I also respect your chaos judgment. Cheers, Bo
Re: InsetBibtex and InsetCommandParams
Bo Peng wrote: Please see my other message. What Andre envisages is rolling InsetCommandParams into the insets. That could be done, of course, but there are at least some reasons not to do it. The reasons not to do it are the same as the reasons to have InsetGraphicsParams be separate from InsetGraphics, so this has nothing to do with ICP as such. Another option, perhaps the one you have in mind, is to ditch ICP altogether here and do for InsetBibtex what is presently done for InsetGraphics and InsetExternal, namely, to give them there own parameter class built from scratch. But I can see no good reason to do that. And at present, there is massive code duplication in those two classes. I don't see why we should add to the chaos. I have had limited experience with InsetCommand, all of them were pretty negative. In the case of InsetBibtex, making a comma separated string as the core structure, and parsing it each time looks really awkward to me. I agree. The alternative I suggested would avoid this. All of this is a remnant of a much older system, according to which an inset's data was stored simply in the form of a LaTeX command string. I'd rather we stored lists like this: bibfile biblio1 bibfile biblio2 This seems especially important with the embed parameter. It's unusual, but /home/heck,rg/biblio.bib is a perfectly valid filename. It would break our system right now. If this was acceptable before the embedding age, it is not acceptable when two sets of data structure are used to represent basically the same information and we have to keep them synced. I would not hesitate at all, to build EmbeddedFIleList when the inset is loaded, manipulate it, and convert it to the latex string when the inset is saved. This has been done for InsetGraphicsParams where EmbeddedFile is used, and I think this is, IMHO, the right thing to do. I haven't looked enough at IGP to know whether there are potential problems there like the ones we have been discussing here. If so, then so; if not, not. What I do know, as I've said, is that there is massive duplication of code. rh
Re: InsetBibtex and InsetCommandParams
José Matos wrote: On Wednesday 02 April 2008 18:25:11 Bo Peng wrote: Of course I also respect your chaos judgment. Come on this does not help any discussion. :-( Actually, that was meant seriously and nicely. I'd said that there'd be too much chaos if we did something, and Bo was saying he respected that judgment. rh
Re: InsetBibtex and InsetCommandParams
On Wednesday 02 April 2008 18:25:11 Bo Peng wrote: > Of course I also respect your chaos judgment. Come on this does not help any discussion. :-( > Cheers, > Bo -- José Abílio
