I think this first stated happening in 4.0, it was definitely present in 4.1. I thought it might be connected to Bug 797889 - editing amounts in dr / cr behaving oddly so didn't report it separately at the time. recipe: create a new tx enter "ABC" without the quotes into the Description press Enter (i.e. make sure the tx is created) edit the Description by positioning the cursor at | like so "AB|C" type any ordinary char, say, lower case q result "ABqC|" i.e. the cursor has jumped to the end of the Description expected result "ABq|C" i.e. the cursor is just after the char entered so if I wanted "ABquartC" I end up with "ABqCuart" There are some other oddities in editing Descriptions but I haven't been able to work out what is happening as clearly as this example. Hopefully this will be enough to point to the bit that needs fixing.
This seems to be down to this line 236 in quickfillcell.c *cursor_position = -1; The problem above only happens when the insert marker is set before the last character. If I comment the line out, all seems to work but no significant changes have been made to that file so not sure if it is the actual cause.
*** Bug 797975 has been marked as a duplicate of this bug. ***
Created attachment 373883 [details] Demo video When pasting text (instead of writing it) makes it jump when on other characters (besides the last one). Demo video attached (same as the one I uploaded to #797975).
changed hardware to all as Andre isn't using Win also: Andre's video (much better than I could have done! thank you, Andre) shows that it isn't just the last but one char. There is a whole lot of other stuff going on which makes me think Bob's one line change won't be the fix of itself.
*** Bug 797976 has been marked as a duplicate of this bug. ***
I have pushed my change to maint along with another line change. Could you please test by using the next nightly after 15/10/2020... https://code.gnucash.org/builds/win32/maint/ and report back so any further changes can be made.
@Bob, I'm using gnucash-4.2-2020-10-16-git-4.2-57.etc, 2nd to last char is fixed, will keep an eye out for other artefacts [1] unless you fixed something more. [1] Adrien mentions quotes in Bug 797976 and I use matching stuff a lot [] () and so on and I think there may be something there as well unless you've fixed that too?
I think that is the same problem as you reported just he started with say "test text" and by selecting just the text and typing the cursor mark will be last but one character. Any way just tried it and it works for me.
I believe I have reproduced this problem, with GnuCash 4.2+(2020-09-26) on macOS High Sierra 10.13.6. I want to add my observation to the report, for your information. I see the problem on new (unsaved) transactions and in saved transactions. I see it most often in the Notes field, but I can reproduce it in the Description field, and in the Memo field of a transaction with open splits. I see that nightlies after 15. October 2020 have a potential fix. My next step is to try to confirm the fix on my system.
Jim DeLaHunt, you could test with https://sourceforge.net/projects/gnucash/files/Development/Gnucash-Intel-4.2-Inst-212-g44432c5.dmg/download. I built that for users to test another bug, but it does include Bob's commit that he thinks will fix this one.
Tested with GnuCash in Gnucash-Intel-4.2-Inst-212-g44432c5.dmg. Symptoms no longer appear. My canonical test case for this now is a Notes string which ends in something like 12:34h. I select "34" and type "56". With bug, result is "12:5h6". With this new build, result is "12:56h" as expected.
Thanks.
