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

Indicator for parseable facts in gui #467

Closed
ederag opened this issue Nov 1, 2019 · 1 comment
Closed

Indicator for parseable facts in gui #467

ederag opened this issue Nov 1, 2019 · 1 comment
Assignees
Labels
design Design discussions and interesting use cases
Milestone

Comments

@ederag
Copy link
Collaborator

ederag commented Nov 1, 2019

With merged PR #461 and pending #466,
it will be possible to enter anything in the gui separate fields.
The rationale was given in this comment.

It will be possible to enter a fact that can not be parsed,
especially until #465 is solved.
This means that the quick cmdline entry can not be used any longer to edit such a fact.

The recommended way is to stick to facts that can be manipulated through the parser
(both command line and gui cmdline),
so there should be an indicator for safe syntax.

Entries in the gui cmdline can be easily checked:
A simple look at the separate fields that are updated as writing.

Entry in a separate field updates the cmdline text
(which is a single string representation of the fact),
so this is easily check too.

The missing part is whether parsing this cmdline text would yield
the same Fact as the separate fields.

Probably a green light if this is the case,
and orange if the round trip does not work.
Probably not turning to red because that would be obnoxious to people
accepting to loose the ease of the quick cmdline entry.

Of course a change in background color as suggested by @mwilck at the end of #461 (comment)
would be better, but having a single indicator is much simpler.

@ederag ederag added the design Design discussions and interesting use cases label Nov 1, 2019
@ederag ederag added this to the v3.0 milestone Nov 1, 2019
@ederag ederag self-assigned this Nov 1, 2019
@ederag
Copy link
Collaborator Author

ederag commented Nov 16, 2019

No support from anyone so, following #461 (comment) and #461 (comment),
this proposition is abandoned in favor of the stricter #476 PR.

@ederag ederag closed this as completed Nov 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design discussions and interesting use cases
Projects
None yet
Development

No branches or pull requests

1 participant