Skip to content

refactoring workflow #61

Description

@garfieldnate

What I envision from a typical Java IDE experience:

  1. User requests a refactoring
  2. IDE presents list of files that will be updated, allows user to confirm. Just the number of files is also fine.
  3. User can view a preview of the changes to be made.
  4. Some analysis is done to alert the user to potential issues with the changes. For example, perhaps the refactoring of Soar code may be uncertain where a ^<variable>.attribute.name is used, or maybe something went wrong and generated syntactically incorrect code. The user should be able to review these issues before accepting the final changes.
  5. The change should be undoable. We don't currently have any project-level undo stack, so this will be some work.

See also #59, #60.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions