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

Apply IntelliJ formatting to the edited code snippet that comes from the agent #1454

Merged
merged 10 commits into from May 20, 2024

Conversation

odisseus
Copy link
Contributor

@odisseus odisseus commented May 6, 2024

Test plan

Tested manually, mostly on this file.

Things that are confirmed to work (prompts might need to be reworded)

Undoing these operations also works perfectly.

  1. Select all text, prompt "Remove all blank lines".
    • The blank lines will be removed only inside the methods. The blank lines between the methods are removed by the agent but restored by the formatter.
  2. Select a whole method, prompt "Remove all blank lines".
  3. Select a piece of the code that references a variable, prompt "Check that the is not null".
    • This should add some lines of code, growing the selection accordingly.

Intentionally misformatting the file

This flow technically works as expected, but the result might confuse the user.

  1. Open a Java file. Make sure that it has formatting problems, e.g. multiple statements (ending with ;) in the same line.
  2. Select a few lines above and below the misformatted line, and invoke "Cody → Edit Code".
  3. In the prompt, write "Remove all indents".
  4. The result should come out correctly formatted, with the proper indents and each statement in its own line.
    • But if you place a breakpoint inside FixupSession.performInlineEdits, you'll see that the edit arrives from the agent without indents (as requested), and is later formatted by IntelliJ.
  5. Click "Undo" or "Edit & Retry".
  6. The code will return to its original state, complete with the original formatting problem.

Things that don't work

These things seem to be broken in master.

  • In some cases, the selection is smaller than the modified part of the code.
  • If you ask Cody to edit code without selecting a range in the file, the generated code will not be selected a,d the Undo action will be broken.
  • Show Diff action seems to be broken in many cases.

@odisseus odisseus requested a review from pkukielka May 6, 2024 16:38
@odisseus odisseus force-pushed the mg/issue-1112 branch 2 times, most recently from a906a2f to 80b6d56 Compare May 7, 2024 11:06
@odisseus odisseus self-assigned this May 7, 2024
@odisseus odisseus marked this pull request as ready for review May 8, 2024 08:02
@odisseus odisseus marked this pull request as draft May 8, 2024 09:44
Copy link
Contributor

@pkukielka pkukielka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@odisseus odisseus marked this pull request as ready for review May 9, 2024 05:19
@odisseus odisseus marked this pull request as draft May 9, 2024 05:29
@odisseus odisseus force-pushed the mg/issue-1112 branch 3 times, most recently from 33d57cd to b21406b Compare May 13, 2024 10:42
@odisseus odisseus requested a review from pkukielka May 13, 2024 13:20
@odisseus odisseus marked this pull request as ready for review May 13, 2024 14:47
// when the user selects a different snippet in the UI.
// FIXME this causes a problem when the entire file becomes shorter than the original
// selection range.
selectionRange!!.let {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not use !!

Copy link
Contributor Author

@odisseus odisseus May 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that !! is justified here. However, I just confirmed that this FIXME still needs to be fixed...

// by calling triggerFixupAsync() which in turn calls ensureSelectionRange().
// The value of this property does not change
// when the user selects a different snippet in the UI.
// FIXME this causes a problem when the entire file becomes shorter than the original
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that going to be fixed as part of this PR?

Copy link
Contributor Author

@odisseus odisseus May 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have refactored FixupSession to use the RangeMarker from the IntelliJ API. Unlike the dumb data classes such as Range, TextRange etc., the RangeMarker remains tied to its document, and updates itself whenever the document is modified. The downside is that we need to acquire a read lock before creating a new RangeMarker.

This has eliminated the problems with shortening the file. However, I've run into other problems...

@odisseus odisseus marked this pull request as draft May 14, 2024 14:15
@odisseus odisseus force-pushed the mg/issue-1112 branch 6 times, most recently from 317a713 to 6a60cdf Compare May 16, 2024 12:13
@odisseus odisseus requested a review from pkukielka May 16, 2024 13:25
@odisseus odisseus marked this pull request as ready for review May 16, 2024 13:34
@@ -34,6 +34,8 @@ class CodyFormatter {
.createFileFromText("TEMP", file.fileType, appendedString)

val codeStyleManager = CodeStyleManager.getInstance(project)
// This will fail if cursor < range.startOffset + completionText.length
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should not crash whole edit if formatter fails.
Instead we should backoff from formatting, log the error, and continue edit without reformatting.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, this is the current behaviour. However, the root cause (incorrect ranges being passed) still needs to be fixed.

@pkukielka
Copy link
Contributor

LGTM

@odisseus odisseus merged commit bf23b92 into main May 20, 2024
6 checks passed
@odisseus odisseus deleted the mg/issue-1112 branch May 20, 2024 08:39
steveyegge pushed a commit that referenced this pull request May 24, 2024
Closes #1631, partially reverts #1454.

## Test plan

None
steveyegge pushed a commit that referenced this pull request May 25, 2024
Closes #1631, partially reverts #1454.

## Test plan

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

Successfully merging this pull request may close these issues.

None yet

2 participants