> I'm still working on the automatic update upon insertion/removal from a
> buffer.
I hope you can solve the administration problems.
However, I'm still not convinced that this signal/slot thing is the best
solution. I'll explain in more detail below..
> Mind you, making the cutBuffer into a real Buffer (like an emacs
> scratch buffer) does have a certain appeal.
Yes, that is a good idea.
[How to cut insets from one document to another - in this case the clipboard.]
> A weird idea might be to change the interface about and do:
>
> Inset::moveIntoBuffer(Buffer*, cursor, ...);
>
> Then everything we do is via insets and they can "automatically" fill in
> their necessary fields and then hand over the rest of the insertion to
> Buffer::insertInset().
I'm sceptic about this idea, because I think it increases dependencies, and
thus muds the semantics. I'd prefer if the Insets were Buffer ignorant -- as
isolated as possible. The less an inset needs to know about the world, the
easier it is to write one. Also, the less dependencies an inset have, the
easier is it to create them as external modules.
> I'm sure there are probably a number of other areas that could use
> signals/slots in this way (and as demonstrated it would also be
> considerably faster than the scan-through-the-buffer method).
The speed problem is non-existant. We have linear time in document length
search in LyX now, and we only have complaints about the speed when people load
28 MB documents into LyX without enough RAM on the machine.
We do not really need linear time in number of bib insets.
Maybe we are using canons to shoot small birds?
Aren't we trying to fix something that is not broken with a complicated system
of signals, slots, auto-pointers and other advanced techniques?
I think it's a mistake to impose a dependency of buffers into the insets.
Does an inset really need to know the owner of itself?
Don't get me wrong: I think you have come up with a very nice scheme that can
be very useful in many situations, but I think we might be in a different one
where we don't need this machinery. There is no real problem with the linear
time in document length to determine the widest bib item. We should only need
do determine this on rebreaks, and this is already a linear time in document
length operation.
I'd like us to aim for a minimal design. Signals and slots are a fantastic
tool for many purpuses, but it's also a dangerous technique: In many ways,
it's the equivalent of a goto: Completely different contexts can be linked
together with a signal. This is extremely powerful and useful, but it's also
dangerous for many of the same reasons that goto's are dangerous.
I think we should try to keep things as simple as possible. (This also implies
that my apply-method system of functions and values and scopes and stuff is too
complicated. We need to come up with something simpler.)
> On a related topic is the need for Paragraph to be just a list<> or vector<>
> of Insets. This is possibly best described as an InsetParagraph.
>
> class InsetParagraph : Inset {
> private:
> vector<Inset*> paragraph;
> ...
> }
>
> Thus we have defined our tree structure completely in terms of Insets
> since an InsetParagraph can be one of the Insets in the vector.
> InsetText contains just a string of text and so forth. This guarantees
> we can eliminate those silly insetmarkers and so forth. Okay, so a fair
> bit has already been done in this direction so maybe I'm just reiterating
> what we're already doing.
He, we must have had another instance of the mind synchronization phenomenon.
I agree that the Paragraph should be a vector of insets. A vector because the
number of insets in a paragraph is limited, and therefor insertion is not too
expensive.
Now, what about a Buffer like this:
class Buffer : Inset {
private:
list<InsetParagraph *> document;
}
Notice that it's a list rather than a vector, because we want constant time
insertion of paragraphs (the number of paragraphs in a document is much higher
than the number of insets in a paragraph). (Also, this is what we have now,
and it works.)
> Moving a cursor through this structure involves moving through each inset
> in turn (from its beginning to end).
Yes. A question arises in the boundary between insets. Suppose we have two
text insets next to each other ("ple" in bold): "exam" "ple". Then, the
iterator in the first text inset can point to e, x, a, m, and beyond m. The
iterator in the second text can point to p, l, e and beyond e.
The problem arises if we want to point to the position between the m and the p.
This is ambigious, because we can do this both by pointing at beyond the m,
and by pointing directly at the p.
So, the Inset-iterator that we need to define, has to be decide which approach
to use. Maybe, the best solution is that the inset-iterator will internally
keep both iterators. Then, we have fast access to both the character before
the point, and the character after. Nah, we don't need that kind of speed.
Let's just use the second option and only point directly to the p.
This question about the InsetIterator is complex: Obviously, the InsetIterator
needs to be a recursive structure, because our document representation is a
tree, and we need to point all the way down the tree.
So how do we define this InsetIterator? As a vector of low-level iterators?
(A low-level iterator is an iterator that can point directly to a thing, for
instance an LString::iterator, or a vector::iterator.)
> To support fast random access we can easily provide caching
> of the sizes of the insets.
> This might be very useful if we have multiple levels of paragraphs.
I don't get this: With a vector, we have constant time random access within
the paragraphs.
If you are talking about accessing the paragraphs, well, we don't have constant
time access now, and things work. It seems we can manage without more advanced
access.
The main thing is that we can get to a close neighbour from a given paragraph
fast: access time from one paragraph to another is linear time in the distance.
> One good question is: How does a paragraph get to hold
> another paragraph within it?
It just holds a ParagraphInset?
Greets,
Asger
