Autodesk-AutoCAD / AutoLispExt

Visual Studio Code Extension for AutoCAD® AutoLISP
https://marketplace.visualstudio.com/items?itemName=Autodesk.autolispext
Apache License 2.0
83 stars 30 forks source link

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

Open stephen147 opened 3 months ago

stephen147 commented 3 months ago

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):

EnM4st3r commented 3 months ago

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

stephen147 commented 3 months ago

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 commented 2 months ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 3 hours ago

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.