Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > The dispatch function called is not the same dispatch function
| > | > anymore. There might be a reason why we have decided to go through the
| > | > top most dispatch and let that handle the traversement of the dispatch
| > | > hierarchy.
| > | | And what is that reason? I thought it was just a remnant of some
| > old
| > | code practice.
| > This code, the dispatch hierarchy is not very old.
| > And you have to talk to the creators of this "modern" dispatch thing
| > to get the reason, if any.
|
| So, that's what I am doing right now, right? Or is there somebody else?
If it is me you are thinking of, then now.
Andre and J-M was certainly part of that rework.
| > | > If this is an ivalid reason or not I cannot say, but there
| > | > you have it....
| > | | I think it is invalid yes. If the traversal could lead to a
| > different
| > | LyXText then I think we are in serious trouble. If there someone
| > | knowing more than that about that stuff.
| > It is not a different lyxtext that is the problem, but a different
| > dispatch. With this change the dispatch hierarchy is entered not at
| > the top anymore.
|
| I know, I wrote the patch remember? ;-)
|
| More seriously, why is it a problem? The dispatch hierarchy will
| inevitably end-up there so why not take the shortcut? IMHO the code
| looks a lot more cleaner this way.
Yeah, but it also means that some LFUNS, if called from lyxtext must
still use bv.owner()->dispatch(...), else you will not be able to
reach all available LFUNS. (Hmm... or do we call back up to the top if
we don't find the lfun?)
--
Lgb
