Code is getting injected into other files open in VSCode leaving them corrupt

[stephen147]

Describe the bug
Code is getting injected into other files. When debugging and executing a file in VSCode, portions of the code are getting injected into other open files.

To Reproduce
Steps to reproduce the behavior:

1. Open a file and other files.
2. Go to the file you want to debug and run in ACAD.
3. Run the code.
4. This is where I don't know, why or how it happens but the code that I'm debugging gets injected into the other open files and they are saved leaving them corrupt.

Expected behavior
For step 4 above not to happen.

Desktop (please complete the following information):

• OS: Windows 10 Pro (Build 19045)

[EnM4st3r]

im always working and debugging with multiple files open, never experienced something similar

[stephen147]

I found the issue. When you use the find and replace all in VSCode, this happens. It doesn't open the file(s) and replaces more than it should.

Perhaps, this is associated with this extension so I might leave this open for others to test.

[stephen147]

Nope. I didn't do any replacements this time while I had VSCode open, so this bug is still there.

It's when I have a file open and execute it and then tab over to another tab to modify a different lisp file or something like that.

I don't know when this exactly happens. I'm trying to find an exact way to reproduce this bug.

[Djwhitelion]

Check your defun names. If there is a similar defun name and that file is loaded in autocad. It can load the other defun in a loaded lisp instead. If you run similar code in other files. And call them the same. They can be called between them.

Edit.
Go to autocad. In commandfeald run "AP".
Check your open lisp files.
Check those files if you see your own.
Check to see if they have the defun you want to run.
After that. Check if the file you have, have defun's that are similar as the other files. And if those that do, have the files in a search path in autocad.

When I write code I have some code I run in many files. Same defun. Same file. So I took it out of the main lisp files and had it as it stand alone lisp. As long as it is loaded. It works. And if you need a variant of that defun. Just copy it and rename the defun and make the changes you need to make. One of them is for example for me when adding a folder in search path for autocad. If I need to make or write something in an outside of AutoCad's normal folders. I want to add that folder to search path just to make my life a tad easier. Same with the code that removes it when the code is finished running. And when making a .vlx. that file needs to be added inn to it. Unless you make an "support" .vlx maby that have all "support" files inside. I might actually start doing that myself going forward 😂👍😁

[stephen147]

These are the steps to reproduce the bug at least for me anyway.

1. Open file A with the contents:

(defun test () 
  (princ "Test")
)

(test)

2. Open File B with the contents:

(defun test () 
  (princ " Me")
)

(test)

3. Run the code on file B.
4. Change the defun name test to testme on both File A and File B. In my experience change any part of the code will have the same effect.
5. Switch back to file A and evaluate the code.
6. File B now gets injected with the code.

For step 5, the same happens when you save the file. This only happens sometimes.

[chris-harling]

This is certainly an issue for me. From what I can tell it seems to do with committing changes. It does not seem to be a find & replace or similar named function issue for me. I'm getting entire 600+ line files getting overwritten with other files.
I've only noticed it to be an issue with whatever files were open at the time. Typically for me this is a few .lsp scripts and the working tree.

I'll try to narrow it down and see if I can make it repeatable instead of hearsay.

One sort of workaround I've found is ctrl+z will undo the changes in a single step.

[chris-harling]

Found a repeatable sequence.

1. open somefile.lsp and make some changes (do not save)
2. open anotherfile.lsp
3. press F5 to debug anotherfile.lsp

BAM! pressing that F5 takes the entire contents of anotherfile.lsp and overwrites those lines in somefile.lsp.

Workaround: Make sure you Save All in VSCode before starting debug.

[jennbushey]

When I have two .lsp files open side by side in VS Code, editing one file causes it to be overwritten by the other file when the focus changes to the other file.

For example:
somefile.lsp has 50 lines of code and anotherfile.lsp has 75. Editing anotherfile.lsp and then switching focus to somefile.lsp causes the first 50 lines of anotherfile.lsp to be replaced by the contents of somefile.lsp. The whole code is replaced if somefile.lsp is the longer code.

Workaround: Change the language mode of one or both files to "Plain Text"

[GoCoder7]

I can reproduce the same family of corruption behavior, and I found what looks like a very strong root cause in the extension code.

I originally suspected another AutoLISP extension in my setup, but after tracing the edit paths, the bug appears to be in AutoLispExt's formatter implementation itself.

In the installed extension bundle, the document formatter is implemented roughly like this:

provideDocumentFormattingEdits(document) {
  let activeTextEditor = vscode.window.activeTextEditor;
  if (activeTextEditor == undefined) return [];

  let fmt = LispFormatter.format(activeTextEditor.document, null);
  return [vscode.TextEdit.replace(utils.getFullDocRange(activeTextEditor), fmt)];
}

The important problem is that it ignores the document parameter and instead formats window.activeTextEditor.document.

That means if formatting is invoked for file B while file A is the active AutoLISP editor, file B can be replaced with file A's content. That matches the reports in this issue very closely:

• one open .lsp file overwriting another
• corruption after focus changes / save / debug / run workflows
• Ctrl/Cmd+Z restoring the file in a single step

I also verified that another AutoLISP extension in my setup does not have a full-document background replace path, so this looks very specifically tied to AutoLispExt's formatter behavior.

In my setup, [autolisp].editor.defaultFormatter was set to Autodesk.autolispext, which makes this even more suspicious.

Possible trigger paths:

• Format Document / Format Selection
• format-on-save if enabled anywhere
• any debug/run/save workflow that ends up invoking the formatter for a non-active document

Workarounds that seem reasonable until this is fixed:

• disable AutoLispExt as the default formatter for AutoLISP
• disable format-on-save for AutoLISP
• Save All before debug/run
• temporarily switch affected files to Plain Text if needed

The formatter should use the document argument passed into provideDocumentFormattingEdits / provideDocumentRangeFormattingEdits, not window.activeTextEditor.document.