GNOME Bugzilla – Bug 469041
Wrong cursor positioning tabbing through last transaction
Last modified: 2018-06-29 21:46:38 UTC
In auto-split ledger mode (and possibly elsewhere): Expected behavior: - Select a split transaction other than the last one in the register. - Edit the blank split. - Use tab to exit the (edited) blank split. - The cursor moves to the new blank split. Erroneous behavior: - Select the blank transaction at the end of the register. - Edit the blank split. - Use tab to exit the (edited) blank split. - The cursor moves to the transaction split, instead of the new blank split. Source: I had a terrible time trying to route this one out. I finally resorted to stepping through the code in gdb in two different versions (2.2.2 and 1.8.11, which doesn't exhibit the problem) simultaneously, looking for differences. The turning point was the call to gnc_split_register_find_split() on line 352 in gnc_split_register_move_cursor(). The old (working) version returns true, setting new_virt_loc to the location for the new blank split. The current (malfunctioning) version returns false, setting new_virt_loc to the current_cursor_loc in reg->table (which is the Transaction split). As it turns out, gnc_split_register_find_split() was modified by r14345 to fix Bug #343798. (Chris even mentions in his revision comment that the change might do strange things to cursor motion.) When I undid the change (removing the "&& s" criterion on line 228), the behavior of the two cases above matched (tabbing off the end of the edited blank split put the cursor on the new blank split). Now, since the change was made to fix another bug, I doubt the solution is simply to reverse r14345. Unfortunately, my understanding of the register is just about nil, so I can't suggest a proper fix. Ideas?
Michael, First off, congratulations! You've stuck your head in a pile of code that few people have dared to brave. And now, you probably know it better than anyone on earth, save maybe 2 people. As you can tell, much of the register code is pretty close to incomprehensible. Our priority has been to prevent crashes and data corruption. In the process, we've accepted some anomalous behavior (read: less severe bug). Since you obviously have some time, aptitude and an interest in GnuCash, I'll suggest that the most efficient way to improve things is to join in the effort to finish the complete-from-scratch rewrite of the register. It is completely functional already, although not feature-complete. It currently lives on the register-rewrite branch, but it sounds like we'll be merging that development into trunk sometime soon (on GnuCash time-scales, that is.) Why not come introduce yourself on gnucash-devel or, even better, in #gnucash, and we can suggest some areas to hack that won't be quite so frustrating as this one.
*** This bug has been marked as a duplicate of 347474 ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=469041. Please update any external references or bookmarks.