Angus Leeming wrote:
Abdelrazak Younes wrote:
Could be a good idea. But and this is a big BUT, I'd argue that if an
lfun needs to call another lfun, then that's a design problem. So if
you prefer, I can rework my patch so that there is no dispatch call
any more.
That's certainly not true. Many of the inset LFUNs are invoked from
outside of LyX (or from the fronetend) as a different LFUN because the
outside has no knowledge of which inset this applies to. The outer-level
dispatch finds the inset and then passes the new LFUN to the inset's
dispatch.
Again, look at the incriminated LFUNs before making up your mind.
For example, my patch change this in text2.C:
// set layout over selection and make a total rebreak of those paragraphs
void LyXText::setLayout(LCursor & cur, string const & layout)
BOOST_ASSERT(this == cur.text());
// special handling of new environment insets
BufferView & bv = cur.bv();
BufferParams const & params = bv.buffer()->params();
LyXLayout_ptr const & lyxlayout = params.getLyXTextClass()[layout];
if (lyxlayout->is_environment) {
// move everything in a new environment inset
lyxerr[Debug::DEBUG] << "setting layout " << layout << endl;
- bv.owner()->dispatch(FuncRequest(LFUN_LINE_BEGIN));
- bv.owner()->dispatch(FuncRequest(LFUN_LINE_END_SELECT));
- bv.owner()->dispatch(FuncRequest(LFUN_CUT));
+ dispatch(cur, FuncRequest(LFUN_LINE_BEGIN));
+ dispatch(cur, FuncRequest(LFUN_LINE_END_SELECT));
+ dispatch(cur, FuncRequest(LFUN_CUT));
I have verified via step by step debugging that we end up doing exactly
that. Don't you think that this is a waste of CPU cycles? The update
machinery is done anyway because this LyXText::setLayout() method is
called only twice in two LFUNs in text3.C: LFUN_FLOAT_LIST and LFUN_LAYOUT.
Abdel.
