On Fri, Nov 02, 2001 at 01:47:35PM +1000, Allan Rae wrote: > AFA stability is concerned, any change to a stable system will cause a > temporary instability. This is a fact.
Yes. But as you said "temporary". > Many people view temporary instability as a transition state -- for > example, from a standing position lift one foot in preparation to start > walking: you have just caused a temporary instability which you have had > to balance. And it is worthwhile: Otherwise you won't be able to move at all. > Now, some may argue that LyX is currently _not_ a stable system. It obviously isn't. > So another action causing an additional instability could cause a > collapse unless the root cause of the existing instabilities is addressed > -- this is the equivalent of going to a LyX Developers Meeting and > drinking the bar dry and then attempting to stand on one leg. > > So do you want to attempt to fix something which isn't causing a problem > but may introduce additional instability or do you want to address areas > which are actually causing instabilities? Pretty easy: Don't fix appearances, fix the cause. If the cause lies in the core, fix the core. Break it into sherds and reassemble it. Maybe I should really give an example: Old Mathed was working. Pretty well actually, and it was the only reason that I started using LyX. It had a few quirks which looked easily fixable from an ordinary user's point of view. But, alas, they were not. Not being able to fix some drawing glitch easily (or in this case not being able to fix it at all) is _not_ a problem of the user interface. It is a hint to more serious hidden troubles. And those have to be fixed. Better now than at any unspecified point in the future when more features have been added and more "client code" relies on the broken core. [Btw, fixing core stuff usually helps to simplify "user stuff" too: The implementation of the old MathFracInset needed 157 lines spilled over three files. Currently math_fracinset.C handles all of it (including the new support for \atop) in 63 lines (of which 26 are "real code"). I certainly do not claim that these lines are free of bugs, but I am pretty sure that every bug in there could be fixed within a minute. And yes, "fixing" it took almost a year and it was unusable in the meantime. But I firmly believe it was worthwhile.] Andre' -- Andr� P�nitz .............................................. [EMAIL PROTECTED]
