You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: When a user is typing in the code editor, we currently commit their edits continuously. This approach is not ideal in some cases, as an incompletely-typed edit is often syntactically strange, and can be much more disruptive to the graph state than the completed edit would be.
Solution: Allow the code editor state to diverge from the module in some "disruptive state" situations. The editor would track edits that have not been committed to the module. The editor would display these uncommitted changes like an inline diff, and offer an option to force committing. As the user continues editing, if the source code leaves the disrupted state, the changes will be automatically committed. If the user makes changes somewhere else in the module while uncommitted edits are present, and those changes are not themselves disruptive, those changes would still commit automatically.
Pros:
This would improve handling of bugs in which the code editor is not able to commit a certain edit (see: Code editor produces incorrect result #11798); currently we reject any unrepresentable edit, and display an error message. Cases that cause this are rare, but it is not possible to guarantee they never happen. If we were to accept these edits within the code editor, display them as uncommitted, and allow the user to keep editing until they are syntactically acceptable, these cases would not cause any disruption.
This would allow us to prevent code editor edits from unnecessarily disrupting the graph, especially for other users: We could recognize disruptive edits (e.g. that destroy all nodes, or cause a currently-used method in the module to be lost), and instead of automatically committing these changes add them to the uncommitted state; the user can continue typing until the edit is no longer disruptive and is automatically committed, or can click a button to force the edit to be committed.
Cons: It will add a lot of complexity to the CodeEditor logic.
The text was updated successfully, but these errors were encountered:
Problem: When a user is typing in the code editor, we currently commit their edits continuously. This approach is not ideal in some cases, as an incompletely-typed edit is often syntactically strange, and can be much more disruptive to the graph state than the completed edit would be.
Solution: Allow the code editor state to diverge from the module in some "disruptive state" situations. The editor would track edits that have not been committed to the module. The editor would display these uncommitted changes like an inline diff, and offer an option to force committing. As the user continues editing, if the source code leaves the disrupted state, the changes will be automatically committed. If the user makes changes somewhere else in the module while uncommitted edits are present, and those changes are not themselves disruptive, those changes would still commit automatically.
Pros:
Cons: It will add a lot of complexity to the CodeEditor logic.
The text was updated successfully, but these errors were encountered: