There's also cutting, using either ctrl/cmd-X or Edit>Cut Split? https://bugs.gnucash.org/show_bug.cgi?id=797249 https://github.com/Gnucash/gnucash/pull/517
Regards, John Ralls > On Jun 5, 2019, at 3:04 PM, Adrien Monteleone > <adrien.montele...@lusfiber.net> wrote: > > Update on the bug. > > I just tested this under the following circumstance: > > 1. I started entering a transaction with a description that produced an > auto-fill of several splits. > 2. The auto-fill contained 2 splits anchoring to the current register. > 3. Attempting to right-click and ‘delete split’, using the toolbar button, or > using the Transaction > Delete Split menu entry on the 1st anchoring split > fired the warning and told me I *cannot* delete this split. My only choice > was to accept this, leave the split in place and proceed. > 4. Attempting to delete the second anchoring split, by either means, was > successful, without warning, and without blowing up the transaction, because > there was a previous anchoring split still tying it to the current register - > results as expected. > > I also tested a fresh transaction with a new description and deleted the > anchor split. It erased the transaction completely. Perhaps it should either > still fire the warning, or at least leave you editing the transaction without > deleting date/num/description/notes, et cetera until you hit Enter to commit. > > Finally, I tested entering another split into a fresh transaction, without > putting any memo or amount on the anchoring split. When I tried to delete the > anchoring split, I received the warning and was not allowed to delete it. > > So it seems the last of the inconsistent behavior is when entering a fresh > transaction and trying to delete the anchor split before entering other > splits. I’ll file a bug on this shortly. > > Regards, > Adrien > >> On Jun 5, 2019, at 4:51 PM, Adrien Monteleone >> <adrien.montele...@lusfiber.net> wrote: >> >> >> >>> On Jun 5, 2019, at 3:06 PM, David Carlson <david.carlson....@gmail.com> >>> wrote: >>> >>> I might as well get this debate started now. Another thread has started a >>> discussion about unsplitting transactions, pointing out that there is an >>> inconsistency between using the various Transaction > [edit] Split keys >>> and the conventional keystroke editing method using the Tab key to navigate >>> around a transaction. >>> I think there should be a warning for any editing action that deletes a >>> split line, including tabbing off the anchor line. Obviously, edits to >>> correct account assignment errors must be allowed and not be overly >>> encumbered by unnecessary warnings. >>> >> >> David, >> >> As I recently (a few minutes ago) noted in that other thread, this is >> allegedly fixed as of 3.4. (https://bugs.gnucash.org/show_bug.cgi?id=796978) >> Perhaps the commit didn’t work as expected. I’m getting ready to test it. >> >> >>> GnuCash, at least in the 2.6.xx series usually prohibits leaving a >>> transaction that contains pending edits without using the Enter key to >>> commit the edits, but it has some exceptions which set up some difficult >>> situations when finally trying to do a manual File > Save. At that point >>> it asks if you want to save edits in some register view which may even be >>> accidental edits or keystrokes that would delete desired data. >>> >>> The most common action (for me) that sets this up is to start an edit in >>> some register then navigate to another register without first saving the >>> pending edit. This easily happens if the user is reviewing results from >>> the Since Last Run assistant especially if a cat crosses the keyboard. >> >> Using Sqlite backend, of course I get instant saves so I don’t see this >> issue anymore, but that sort of ambiguous ’save edits’ question is >> disconcerting if you are pretty sure you’ve committed all transactions, and >> now you’re being told you haven’t. >> >>> >>> I can see the reasoning that often users may need to view other registers >>> to compare the transaction currently being edited to something else, so I >>> do not want to prevent that. I would propose that the tabs containing >>> pending edits flash in some way to catch the user's attention so he can >>> find his way back to see if it was cat-tracks or a real pending edit. >> >> Interesting idea. Though this might interfere with the custom tab colors, I >> like the idea of some visual indicator that something has been edited and >> needs attention. (perhaps a bold or italic typeface change?) Flashing >> however I would not be in favor of. >> >>> >>> There are also a couple of cases where attempting to cancel a pending edit >>> does not correctly restore the transaction to the previous state which >>> could be fixed at the same time other pending edit behavior is addressed. >> >> Sounds like a bug. >>> >>> Another situation where pending edit behavior is inconsistent is when >>> editing scheduled transactions, the Enter key may or may not save the edit, >>> depending on which field the focus happens to be in. I think that the >>> enter key should always save pending edits. >> >> Again, I’d think a bug. I would expect Enter to always commit an edit. >> (especially since the Help manual says as much, or so I recall last time I >> read it) >>> >>> Finally, I will throw out a radical suggestion that all edits get their own >>> new window instead of happening within a certain register view with a >>> certain "anchor" account which has special behavior compared to other split >>> lines. This Edit window would not be tied to any account and would be >>> obviously not saved as long as it exists. >>> >> This already exists as the ‘General Journal’ (Tools menu) It’s your choice >> to use it. Though it is not implemented for only the currently edited >> transactions, but the entirety of your data file. >> >> Regards, >> Adrien >> > > > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please see > https://wiki.gnucash.org/wiki/Mailing_Lists for more information. > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
