On Thu, Apr 07, 2005 at 05:10:48PM +0300, Martin Vermeer wrote:
> > I know I am repeating myself, but we should understand the
> > LFUN_FINISHED stuff before doing that. Either it makes sense and we
> > should fix it, or it does not, and we should remove it completely.
The main purpose of the LFUN_FINISHED stuff is to make insets more
independent of their parents. They do not have to know _how_ their
parent would handle an LFUN_END, but at most that they _might_ be able
to handle it _somehow_.
The current use of LFUN_FINISHED is 'complicated' because it is a short
cut. The long procedure would be
- Inset decides that it does not handle the request but
does not want to swallow it either because it is quite
sure some of its ancestor will handle (or swallow) it
- Inset pops a slice off the cursor.
- Inset creates a new 'move a bit to the right' request and
start a new full LCursor::dispatch iterating over all
(remaining) slices
The shortcut is
- Inset decides that it does not handle the request but
does not want to swallow it either because it is quite
sure some of its ancestor will handle (or swallow) it.
- Inset changes to current request ro 'LFUN_FINISHED_RIGHT'
which will be handled by the global slice-iterating loop
This basically saves a few cycles.
However, now that I think about it and given your troubles to unterstand
the method we could as well switch to the long procedure. This would
simplify the general dispatch structure by removing these special
LFUN_FINISHED lfuns. We would need some 'dispatch queue' so that a local
handler could return 'success' yet schedules another request. This queue
would also be nice for command-sequence, so I really start to think now
that this might be the better solution.
Andre'
