> Why? Why would we want all Unicode insets to connect to a signal?
> Why would we want all insets connecting to signals?
Aside: Even with many Unicode insets, this is not too bad. I think Emacs uses
around
22 bytes for every single character in a document, so LyX should be able to
handle the same order pretty well.
> It could arguably also be used to create the TOC and TOF lists also. But
> I think Asgers plan (as I understand it) is better suited to that.
Notice that my plan was not a plan, but a rough idea ;-)
The idea was that by adding a method that would execute a function every inset,
we could generalize many operations with one method.
If the action is restricted to only some insets, the function that we apply
should check for this itself. I.e. when invoked on a given inset, it would
first check whether the inset was the correct type, and if not, just return
without doing anything.
Yes, this would not be as efficient as your scheme, because your scheme targets
precisely the insets that are affected, while my idea is much worse, because we
visit all insets.
However, your scheme involves some administration of the signals and slots.
What if we cut to the clipboard? What if we paste into a different document?
The answer to all of these questions might be easy, but the point is that we
have to take care of these details. And when there are too many details to
take care of, it's easy to miss one, and we get the bugs that are hard to find.
I'd like us to come up with a design where we avoid many of these details.
Now that I think about it some more, I feel an "apply" method that will execute
a function on an inset, makes much sense: There is no administration involved,
we have a natural plug for the scripting language, and we avoid the extra
memory usage.
Of course, the apply idea is not as efficient speed-wise: We have to visit all
insets to do the operation, but I'm positive this is no problem in reality.
So, in order to determine the width of the widest bib-item, we would write a
function like this:
int widest_bib_item(Inset const * inset, int widest_so_far) {
if (inset->name == "Bib" && inset->width > widest_so_far)
return inset->width;
return widest_so_far;
}
and then do something like this on the document inset:
int widest_bib_item = document->apply(widest_bib_item, 0);
--
I strongly feel it's necessary to have intraspection in all insets: Each inset
should be able to identify itself to the world (even if we don't adopt this
apply-scheme). Maybe the enum-scheme was bad because of the administration
involved in the source files, but we need to come up with something. A raw
string interface will be fine with me, and useful in other situations...
Greets,
Asger
