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

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:

Open a file and other files.
Go to the file you want to debug and run in ACAD.
Run the code.
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)

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

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.

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.

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 😂👍😁

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

Open file A with the contents:

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

(test)

Open File B with the contents:

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

(test)

Run the code on file B.
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.
Switch back to file A and evaluate the code.
File B now gets injected with the code.

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

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.

Found a repeatable sequence.

open somefile.lsp and make some changes (do not save)
open anotherfile.lsp
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.

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"

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.

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

EnM4st3r commented on May 22, 2024

stephen147 commented on May 28, 2024

stephen147 commented on Jun 27, 2024

Djwhitelion commented on Jun 29, 2024

stephen147 commented on Jun 30, 2024

chris-harling commented on Aug 27, 2024

chris-harling commented on Sep 6, 2024

jennbushey commented on Aug 2, 2025

GoCoder7 commented on Jun 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions