On Mon, 8 Mar 1999, Asger Alstrup Nielsen wrote:
> > Example code for using signals to reduce the need for rtti or
> > inset codes. No need to identify insets, they identify themselves by
> > connecting to appropriate signals. This scheme means we don't have
> > to scan a buffer looking for particular inset types.
> >
> > NOTE: this doesn't solve all problems related to special case handling
> > of insets. Those special cases remaining can be eliminated
> > by a homomorphic hierarchy: remember the main reason we need
> > to identify a particular inset is so we can call a method that
> > only it supports. If all insets support that method but default
> > to no action we no longer need special case testing. We
> > shouldn't just spread existing methods across all insets though
> > we need to identify real special case instances and plan better
> > since we might be able to avoid that special case in better ways.
>
> That was pretty neat code.
> The only negative thing I can say about it is that the Buffer will be cluttered
> with signals, and we don't want that...
It shouldn't be cluttered because we don't need to do these sorts of
things with each and every sort of inset. This is just meant as a way of
avoiding the need to scan the buffer looking for specific types of insets
to ask them specific questions like "What is the widest bibkey entry so I
can format the References section neatly?" and so on.
We shouldn't need that sort of thing for every inset. In fact bibkeys are
the only special case I can think of. Maybe there are others but they are
very small in number. Hmmm... probably labels also since we need a list
for the InsertRef popup. I'm sure someone might argue that open/close all
floats/footnotes etc. could also be done this way but I'm not sure it'd
work.
Another use of this sort of scheme is to link references to labels.
This scheme would automatically update all references when a label was
changed. This is generally a good thing (especially for Garst's scripts).
If you don't want to update all references to the new label then we simply
create a new inset with the changed label (and no connected references)
and leave the old label somewhere safe (at the end of the document? or
leave it where it was). Note that a reference in this case is using the
actual text of its label from the label inset. Also note that these
signals are not in Buffer.
> What about using a similar technique, but in a higher level fashion?
> Instead of having customized signals for every little thing, we will instead
> have a generic Variable-system, a generic Function-system, and a generic
> Scoping system.
> Together, this will define a very general storage facility, and with this, we
> can do all sorts of general things.
> So, we will define a bunch of Variables, and a bunch of Functions that can be
> applied to all insets in a document in one go. By giving each Inset a specific
> Scope, we can target exactly the Insets we want to, and hopefully do all these
> queries with only one interface.
> It's just a rough idea, and it needs some more thought, but I thought that I'd
> just throw it into the air.
I'm not entirely sure I understand this proposal.
[...]
> Then we would have a method "apply" in all insets, that would take a Function
> and apply it to some passed Variable.
So who decides what a Scope is? How do we inform each inset of its scope?
Will a scope allow targeting of specific inset types (like Bibkey) and
specific document scope (say only within the first chapter)?
Won't we end up with just another variation of Inset::Codes if we allow
targeting of specific insets this way? and how do we cope with new insets
or even generic insets that simply wrap a scripted inset handler?
> The idea is to do something higher-level that is very general, and hooks nicely
> into a scripting language. Anyway, just a thought...
I'd like to hear more about this thought.
Allan. (ARRae)
