Perhaps that would be a better behavior for the current jump button. Regards, John Ralls
> On Jun 28, 2019, at 9:20 AM, David Carlson <david.carlson....@gmail.com> > wrote: > > I would like to throw out a new suggestion to add a permanent menu item to > the account register window that would jump to the current transaction in > the journal view, where there is no anchor account. This would allow > editing without worrying about whether an anchor account split is being > edited. > > David Carlson > > On Fri, Jun 7, 2019, 9:07 PM Adrien Monteleone < > adrien.montele...@lusfiber.net> wrote: > >> I figured as much, but suggested it anyway at least as a temporary >> workaround. I do see the utility of an edit-only tab. >> >> Regards, >> Adrien >> >>> On Jun 7, 2019, at 8:37 PM, David Carlson <david.carlson....@gmail.com> >> wrote: >>> >>> Returning to Adrien's comment on my Edit window Suggestion: >>> >>>>> 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. >>>> >>> >>> My reasoning for suggesting a dedicated edit window for each transaction >> edit is to serve a completely different purpose than that served by the >> General Journal, but it may share some code in an implementation. If each >> transaction edit was in it's own dedicated window, they would all be very >> easy to find and commit or cancel at a later time. Then the possible >> ambiguity of having some pending edits in search windows or the General >> Ledger would also be avoided. There may be a better coding technique to >> implement this, especially in SQL, so I do not want to be so specific to >> prevent the developers from thinking creatively in an implementation. >>> >>>> David Carlson >> >> >> _______________________________________________ >> 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. _______________________________________________ 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.
