On 09/24/2011 05:03 PM, Richard Heck wrote:
The solution, I'd think, would be to let users choose what appears in
the TOC under Preferences.
The whole thing, I think, could be done at a lower level of inheritance.
There are many insets that repeat (almost) the same code over and over
again.
Insets could have a method to provide just a string to put to TOC, and
filling the TOC could then be done by a more general method.
In that way every Flex inset could have its own entry in the TOC, and
its .layout/.module file should tell us whether to include it in the TOC
or not. A module for Sweave users could just extend the ERT inset,
enabling its inclusion in the TOC.
I do not have the whole (or any) structure of the code in my mind
(yet:), can you tell whether this would be possible, and desirable?
-×-×-
Studying the code for InsetNote I spotted a part of the code in
doDispatch that no other inset has. I think that cur.forceBufferUpdate()
is not needed here, what do you say?
case LFUN_INSET_MODIFY:
cur.recordUndoInset(ATOMIC_UNDO, this);
string2params(to_utf8(cmd.argument()), params_);
setButtonLabel();
// what we really want here is a TOC update, but that means
// a full buffer update
cur.forceBufferUpdate();
break;
Regards,
P
