Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Edit prior data without undoing subsequent data #62

Open
the-solipsist opened this issue Dec 16, 2021 · 6 comments
Open

Edit prior data without undoing subsequent data #62

the-solipsist opened this issue Dec 16, 2021 · 6 comments

Comments

@the-solipsist
Copy link

One common occurrence is that I reach the 3rd or 4th data entry field, and then realize that I've entered the wrong date (which is the 1st data entry field). Currently, in order to correct this, I need to undo all the data I've entered, correct the date, and re-enter all that data. The other option is to enter it into the journal, and then remember to go edit the entry manually using a text editor.

Enhancement request: Allow users to navigate to previous data fields and edit them without having to undo all subsequent data fields.

@hpdeifel
Copy link
Owner

This issue bugs me all the time, too. It's a bit weird to solve in the current "question/answer" design. We could remember all later answers when the user presses undo multiple steps and then prefill the input field with the old answer when she goes forward again.

I think the ultimate solution to this would be to change the current design to a form based one, so that iadd mostly behaves like a website or a traditional GUI app. In such a design multiple input fields are shown at the same time and the user can freely switch between them, which would be much more intuitive than prefilled answers, imho.

@hpdeifel hpdeifel changed the title [Enhancement] Edit prior data without undoing subsequent data Edit prior data without undoing subsequent data Dec 22, 2021
@the-solipsist
Copy link
Author

I think the ultimate solution to this would be to change the current design to a form based one, so that iadd mostly behaves like a website or a traditional GUI app. In such a design multiple input fields are shown at the same time and the user can freely switch between them, which would be much more intuitive than prefilled answers, imho.

Could you do that while retaining the auto-suggestions so that people can just press enter if (a) all the amounts and accounts from a previous transaction apply, and (b) the inverse amounts (e.g., ₹-750.00 in Assets:Cash when Expenses:Gift is ₹750.00) are auto-suggested when filling out the form?

I wouldn't want to remove the advantages of hlegder-iadd over existing web forms (such as hledger-web):
#39 (comment)

@simonmichael
Copy link

hledger add has this undo feature. I suspect being based on the wizards library might help the implementation. If so, I wonder if it would be possible/useful to base hledger-iadd on wizards as well ? Possibly even the same wizards defined for hledger add, though that's a long shot ? wizards advertises itself as UI independent, so in theory you can define a wizard (sequence of interactions) once and reuse it for multiple UIs.

@hpdeifel
Copy link
Owner

Could you do that while retaining the auto-suggestions so that people can just press enter if (a) all the amounts and accounts from a previous transaction apply, and (b) the inverse amounts (e.g., ₹-750.00 in Assets:Cash when Expenses:Gift is ₹750.00) are auto-suggested when filling out the form?

I wouldn't want to remove the advantages of hlegder-iadd over existing web forms (such as hledger-web): #39 (comment)

yes, of course. That's the reason I haven't started implementing such a UI. I want to make sure the existing workflows keep working - ideally down to the exact same key presses.

@hpdeifel
Copy link
Owner

hledger add has this undo feature. I suspect being based on the wizards library might help the implementation. If so, I wonder if it would be possible/useful to base hledger-iadd on wizards as well ? Possibly even the same wizards defined for hledger add, though that's a long shot ? wizards advertises itself as UI independent, so in theory you can define a wizard (sequence of interactions) once and reuse it for multiple UIs.

I've had a quick look at wizards, but it seems like it's specifically tailored to REPL-style applications, with primitives like line that aren't easily mapped to brick or GUIs.

@simonmichael
Copy link

simonmichael commented Dec 22, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants