Re: About macro and child buffers
Stefan Schimanski wrote: Am 06.03.2008 um 22:34 schrieb Abdelrazak Younes: Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): Please take a look at the two Buffer::updateMacros methods now after my commmit. I is _much_ simpler now. No mutual recursions anymore to get the scopes right for macro definitions inside font changes or environments. Probably there is even more room for simplification now with the new global semantics. Yes, it is much simpler. Still, I think most (all?) of this code should go to the insets. Abdel.
Re: About macro and child buffers
Am 11.03.2008 um 11:48 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Am 06.03.2008 um 22:34 schrieb Abdelrazak Younes: Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): Please take a look at the two Buffer::updateMacros methods now after my commmit. I is _much_ simpler now. No mutual recursions anymore to get the scopes right for macro definitions inside font changes or environments. Probably there is even more room for simplification now with the new global semantics. Yes, it is much simpler. Still, I think most (all?) of this code should go to the insets. You mean the different cases in the updateMacros loop? Probably one can move some of it to the insets. Will look into this. Stefan
Re: About macro and child buffers
Stefan Schimanski wrote: Am 11.03.2008 um 11:48 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Am 06.03.2008 um 22:34 schrieb Abdelrazak Younes: Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): Please take a look at the two Buffer::updateMacros methods now after my commmit. I is _much_ simpler now. No mutual recursions anymore to get the scopes right for macro definitions inside font changes or environments. Probably there is even more room for simplification now with the new global semantics. Yes, it is much simpler. Still, I think most (all?) of this code should go to the insets. You mean the different cases in the updateMacros loop? Yes. Probably one can move some of it to the insets. Will look into this. Thanks. Abdel.
Re: About macro and child buffers
Stefan Schimanski wrote: Am 11.03.2008 um 11:48 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Am 06.03.2008 um 22:34 schrieb Abdelrazak Younes: Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): Please take a look at the two Buffer::updateMacros methods now after my commmit. I is _much_ simpler now. No mutual recursions anymore to get the scopes right for macro definitions inside font changes or environments. Probably there is even more room for simplification now with the new global semantics. Yes, it is much simpler. Still, I think most (all?) of this code should go to the insets. You mean the different cases in the updateMacros loop? Probably one can move some of it to the insets. Will look into this. Just some hints and suggestion: - I am not sure the children_positions cache is needed as you can retrieve the same information now thanks to toc_backend_[child]. But if it is really needed for speed reason, I would let child documents register themselves in InsetInclude::updateLabels(), a new method Buffer::setChild(Buffer , DocIterator const ) comes to mind. - we need a new virtual method: Inset::updateMacros() implemented in InsetText and in MathMacroTemplate at least. I think I'd call InsetText::updateMacros() inside InsetText::updateLabels() for example. - about updateMacroInstances(), I don't see why this is needed. Maybe you could just call updateMacros() inside InsetMathNest::addToToc(). Of course what this all means is that updateLabels() and addToToc() should probably renamed to updateBufferContext() and realizeBufferContext(). Abdel.
Re: About macro and child buffers
Stefan Schimanski wrote: Am 06.03.2008 um 22:34 schrieb Abdelrazak Younes: Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): Please take a look at the two Buffer::updateMacros methods now after my commmit. I is _much_ simpler now. No mutual recursions anymore to get the scopes right for macro definitions inside font changes or environments. Probably there is even more room for simplification now with the new global semantics. Yes, it is much simpler. Still, I think most (all?) of this code should go to the insets. Abdel.
Re: About macro and child buffers
Am 11.03.2008 um 11:48 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Am 06.03.2008 um 22:34 schrieb Abdelrazak Younes: Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): Please take a look at the two Buffer::updateMacros methods now after my commmit. I is _much_ simpler now. No mutual recursions anymore to get the scopes right for macro definitions inside font changes or environments. Probably there is even more room for simplification now with the new global semantics. Yes, it is much simpler. Still, I think most (all?) of this code should go to the insets. You mean the different cases in the updateMacros loop? Probably one can move some of it to the insets. Will look into this. Stefan
Re: About macro and child buffers
Stefan Schimanski wrote: Am 11.03.2008 um 11:48 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Am 06.03.2008 um 22:34 schrieb Abdelrazak Younes: Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): Please take a look at the two Buffer::updateMacros methods now after my commmit. I is _much_ simpler now. No mutual recursions anymore to get the scopes right for macro definitions inside font changes or environments. Probably there is even more room for simplification now with the new global semantics. Yes, it is much simpler. Still, I think most (all?) of this code should go to the insets. You mean the different cases in the updateMacros loop? Yes. Probably one can move some of it to the insets. Will look into this. Thanks. Abdel.
Re: About macro and child buffers
Stefan Schimanski wrote: Am 11.03.2008 um 11:48 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Am 06.03.2008 um 22:34 schrieb Abdelrazak Younes: Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): Please take a look at the two Buffer::updateMacros methods now after my commmit. I is _much_ simpler now. No mutual recursions anymore to get the scopes right for macro definitions inside font changes or environments. Probably there is even more room for simplification now with the new global semantics. Yes, it is much simpler. Still, I think most (all?) of this code should go to the insets. You mean the different cases in the updateMacros loop? Probably one can move some of it to the insets. Will look into this. Just some hints and suggestion: - I am not sure the children_positions cache is needed as you can retrieve the same information now thanks to toc_backend_["child"]. But if it is really needed for speed reason, I would let child documents register themselves in InsetInclude::updateLabels(), a new method "Buffer::setChild(Buffer &, DocIterator const &)" comes to mind. - we need a new virtual method: Inset::updateMacros() implemented in InsetText and in MathMacroTemplate at least. I think I'd call InsetText::updateMacros() inside InsetText::updateLabels() for example. - about updateMacroInstances(), I don't see why this is needed. Maybe you could just call updateMacros() inside InsetMathNest::addToToc(). Of course what this all means is that "updateLabels()" and "addToToc()" should probably renamed to "updateBufferContext()" and "realizeBufferContext()". Abdel.
Re: About macro and child buffers
Am 06.03.2008 um 22:34 schrieb Abdelrazak Younes: Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): Please take a look at the two Buffer::updateMacros methods now after my commmit. I is _much_ simpler now. No mutual recursions anymore to get the scopes right for macro definitions inside font changes or environments. Probably there is even more room for simplification now with the new global semantics. Stefan
Re: About macro and child buffers
Am 06.03.2008 um 22:34 schrieb Abdelrazak Younes: Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): Please take a look at the two Buffer::updateMacros methods now after my commmit. I is _much_ simpler now. No mutual recursions anymore to get the scopes right for macro definitions inside font changes or environments. Probably there is even more room for simplification now with the new global semantics. Stefan
Re: About macro and child buffers
I am sorry to say this only now but I am worried about future maintenance of the code. So, if you agree with me and you have the time, please try to do those change before 1.6.0. I know about the complexity. What I really want to do for some time is the following which dramatically reduces the complexity: Macros should be global, i.e. no scopes anymore. Scopes are there in TeX of course, but I don't think they are really essential for the usual user. This will make the code much much simpler. I was waiting for Manuel Pégourié-Gonnard to update his xargs to implement the needed semantics for LyX. He sent me a snapshot, but didn't release it yet. Stefan
Re: About macro and child buffers
I am sorry to say this only now but I am worried about future maintenance of the code. So, if you agree with me and you have the time, please try to do those change before 1.6.0. I know about the complexity. What I really want to do for some time is the following which dramatically reduces the complexity: Macros should be global, i.e. no scopes anymore. Scopes are there in TeX of course, but I don't think they are really essential for the usual user. This will make the code much much simpler. I was waiting for Manuel Pégourié-Gonnard to update his xargs to implement the needed semantics for LyX. He sent me a snapshot, but didn't release it yet. Stefan
About macro and child buffers
Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. Abdel.
Re: About macro and child buffers
Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): // register macro d-macros[macroTemplate.name()][it] = Impl::ScopeMacro(scope, MacroData(*this, it)); should be done in MathMacroTemplate::updateLabels() this way: // register macro buffer().masterBuffer()-registerMacro(...); I am sorry to say this only now but I am worried about future maintenance of the code. So, if you agree with me and you have the time, please try to do those change before 1.6.0. Abdel.
About macro and child buffers
Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. Abdel.
Re: About macro and child buffers
Abdelrazak Younes wrote: Stefan, The way we do the macro tables update is not optimal and I think time consuming. I've cleaned up child document handling now except for everything macro related. I believe you can do all this stuff in updateLabels(), please have a look. I had a closer look at the macro stuff. This is really complicated Stefan. WRT child/parent handling, I think you should take the same solution as for the labels and the toc backend, namely that only the _master_ macro table is updated and maintained. IOW, this means that the macro registering presently done in Buffer::updateEnvironmentMacros(): // register macro d->macros[macroTemplate.name()][it] = Impl::ScopeMacro(scope, MacroData(*this, it)); should be done in MathMacroTemplate::updateLabels() this way: // register macro buffer().masterBuffer()->registerMacro(...); I am sorry to say this only now but I am worried about future maintenance of the code. So, if you agree with me and you have the time, please try to do those change before 1.6.0. Abdel.
