Trouble With "Enter" vs. "Tab" (Again)

[David T.]

John and others--

My point about the enter key and its special features is that unlike the other keys that trigger the close transaction function, the enter key does it at every iteration, even though it doesn't take the user out of the transaction. I still don't see the benefit of closing the transaction and staying in it at the same time.

@Ian: I have come to view the Imbalance-USD account as my friend. On my machine, I have this account always open, and check it regularly to see the transactions that need my attention. When I import complex transactions, I have to edit them anyway, and having them all turn up in this account makes it easy to keep track. As I correct a transaction, it disappears from this account.

@Colin: you say you never close a transaction except by using the enter key. That's great; I find that I close transactions all the time by using the tab key, the arrow keys, the mouse and the function keys--as well as the enter key. Most of the rest of these take you out of the transaction in question without benefit of the enter key, and I will assume that the transactions in these cases are closed as well. So, why make the enter key special?

@John: If it's keystrokes you're trying to save, then in your change-the-date scenario, the Enter key is not the most efficient key to use; the up or down arrow keys are. In my copy of Gnucash (2.4.8 on OS X downloaded from the sourceforge dmg), in full ledger or auto-split mode, the Enter key goes from the date field to the action field in the first split, and each subsequent time takes me one line down in the transaction, which can add up to a lot of keystrokes.

Instead, using the up or down arrow from the date field immediately goes to the next transaction (and again, I assume this closes the transaction)--all in one keystroke. It has the added benefit of keeping the cursor in the area of the register that I was in before I chose to change the date (which I prefer). The transaction will "jump" away to its new date.

Certainly, using tab is 5 times this many keystrokes--but again, that's not the point. If the enter key acted as a "go to the next line" key *without* closing the transaction, how would it differ from the other navigation keys, and more importantly, what would be lost by this change? 


Also, if you look at the bug, you'll see that I offered text to be placed in section 8.7 of the Concepts manual.


David


----- Original Message -----

From: John Ralls <jralls at ceridwen.us>
To: David T. <sunfish62 at yahoo.com>
Cc: Users Gnucash <gnucash-user at gnucash.org>
Sent: Monday, November 14, 2011 1:35 PM
Subject: Re: Trouble With "Enter" vs. "Tab" (Again)


On Nov 14, 2011, at 10:24 AM, David T. wrote:

> John--
> 
> I am sorry I missed the details about the Tab key moving to the next field, while the Enter key move to the next line. Frankly, to me that's not the point.
> 
> 
> Ultimately, the point is that the Enter key "finishes the transaction edit" but still keeps the transaction open onscreen. This misleads users, and will cause them to have the kinds of troubles I experienced. I *still* don't understand the reason WHY the Enter key finishes the transaction edit. If there is a functional use-case reason for finishing the transaction edit every time a user presses Enter, I'd really like to hear it. I trying to understand this.

Simple: You entered a transaction, but made a mistake. Perhaps you meant to change the date, perhaps you accepted 
the auto-filled account or amount. Doesn't matter, you need to change something. Let's pick the date, because that's the 
worst-case for what you're asking for. You click on the date with the mouse, fix it, and hit enter.

As written, gnucash makes your change and moves the focus to the next account. If Enter behaved like Tab, you'd have to
advance across the whole transaction (5 enters) or go back to the mouse to click in  another transaction to get it to close. 
In Split view, you'd have to go through every field of every remaining split, or arrow down, or click in another transaction.


> 
> In the absence of such an explanation, would it be such a horrible solution to remove the closing action of the Enter key behavior altogether, and instead have the closing action attached to the empty split situation (as it currently is when the user presses Tab on an empty line)? As an end user, I would be willing to go to Bugzilla and file an RFE bug request for this change, if it seems like it makes sense.

No, it doesn't, as illustrated above.
> 
> Adding a per-transaction nag dialog will NOT help the situation, and I really don't think it would be helpful to add *another* key combination (CTRL-Enter) into the mix. I would rather see the distinction go away altogether.
It wouldn't be per-transaction: It would only stop you "committing" an unbalanced transaction. 
> 
> As for the problem with entering capital gains, you refer to the current functionality as a "hack." That suggests to me that someone purposefully made use of the difference between Tab and Enter to convince Gnucash to behave in a specific way in this instance. Since it *is* a hack, and since you've made it clear that there are unlikely to be fixes to this, I think it should be clearly stated in the documentation that this is an issue. I have filed bug 664054 to address the documentation question.

No, someone purposely made it possible for stock accounts to record splits without affecting the number of shares, but
made the autobalance code put a single share in if the split is open for editing when the transaction is "committed".
Better documentation would certainly be welcome. I hope you'll provide a patch to go with your bug report.

Regards,
John Ralls