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.