On Sun, Apr 10, 2005 at 12:32:19PM +0200, Helge Hafting wrote: > 1. Applying n-root over a selection improved. (Good) > 2. DVI output still matches what's on screen (no change) > 3. "edit->math->computer algebra->maxima" > results still correct. (no change) > 4. An old saved document with the fourth root of 81 > now loaded as the 81th root of four. Saving and > reloading also swaps the n-root components. (Quite bad!)
Looks like you missed one instance of 0 <=> 1 somewhere. > 5. Keyboard navigation is now silly - passing through > an n-root with right-arrow goes under the root first > and then into the n-part, and finally exits > the n-root and moves on through the math. (Bad!) So idxFirst() etc needs to be re-implemented. The default is not sufficient in this scenario. > 6. The third root special now sticks the "3" under > the root sign. (Wrong) So the missing 0 <=> 1 change seems to be in the math parser. Have a look at the bit creating a MathRootInset. > So I wonder if this was the right approach - or would a special > case in pasting be better? This is the right approach. The special case in paste is conceptually wrong. > If we go with this approach, I believe I could track down issue(3). > The "write" part in math_rootinset.C was changed, and we need > a corresponding change wherever the "read" takes place. Issue(6) > is probably not that hard either, or the third root > special could be removed as suggested. > > But what to do about issue(5)? Will that require special cases > for the n-root in math navigation? Where would that be? Have a look at what 'frac' does when entering from the right. > I wonder if this was the right approach - or would a special > case in pasting be better? See above. Andre'
