Skip to content

objectscript.autoAdjustName behavior changed on client-side editing #1559

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

Closed
hsyhhssyy opened this issue May 21, 2025 · 8 comments · Fixed by #1562 · May be fixed by #1563
Closed

objectscript.autoAdjustName behavior changed on client-side editing #1559

hsyhhssyy opened this issue May 21, 2025 · 8 comments · Fixed by #1562 · May be fixed by #1563

Comments

@hsyhhssyy
Copy link
Contributor

In version 3.0.0, the behavior of the aforementioned configuration was adjusted:

  • Change the default value of the objectscript.autoAdjustName setting to false. Now that we have an index of the workspace, we no longer require that a document's name match the file path for the extensions to find it. This setting only affects files that are copied or moved. New files will still have the Class or ROUTINE header generated upon file creation.

However, this change seems to have led to unexpected side effects in client-side editing:
Problem 1: When creating a blank file, the plugin may automatically generate a blank class definition.
Problem 2: When saving server code to disk using Ctrl+S in the Server Explorer, the plugin may unexpectedly modify CLASS package names or ROUTINE names.

Problem 1 may be acceptable, but Problem 2 is not, as it modifies existing code without explicit user consent. This behavior risks users unknowingly committing incorrect code if they fail to notice the altered package name.

Could you confirm if this is the intended behavior and provide some insight into the reasoning behind it?

@isc-bsaviano
Copy link
Contributor

Hi @hsyhhssyy, can you send reproduction steps for the issues please? 1 should have been fixed by #1515, which is in 3.0.0. 2 sounds unrelated to autoAdjustName. I also recommend you upgrade to 3.0.2 if you haven't already.

@hsyhhssyy
Copy link
Contributor Author

Problem 1
https://github.com/user-attachments/assets/83967948-f450-4c0e-b862-7392eef54e13
As shown in the video, when autoAdjustName is set to false, new files are automatically given an extra, unsaved class definition. The autoAdjustName setting was originally added to help prevent this.

Problem 2
https://github.com/user-attachments/assets/2c393604-f343-43b1-913f-c25753c3c05d
In this video, if you press Ctrl + S and save the file to a sub-folder inside the current workspace, an incorrect class definition is inserted.

Possible approach
The simplest workaround seems to be the change proposed in my PR, and also sets autoAdjustName to true by default.
That said, it looks as though these behaviors may be related to recent server-side changes, so it might be worth taking a closer look before deciding on the final fix.

@isc-bsaviano
Copy link
Contributor

Hi @hsyhhssyy , thanks for the videos. Your first problem is expected behavior. When I changed the default for the autoAdjustName setting, some users complained that the class and routine stubs were no longer being generated for empty new files. I agreed that restoring that was desirable behavior, so I exempted that from the setting. Your second issue looks like a bug, and I will investigate. I appreciate the PR attempt but you can close it. I need to look into that isdue more closely.

@isc-bsaviano
Copy link
Contributor

The issue is that when the new file is created via Save As..., the created file event handler is called before the file's content is filled in, so it appears to be empty. I will need to see if there's a way to detect that the file's content is about to be filled in (maybe a small delay)?

@isc-bsaviano
Copy link
Contributor

@hsyhhssyy My fix for your second issue can be tested using the vsix in the zip below.

vscode-objectscript-3.0.3-dev.1562.vsix.zip

@hsyhhssyy
Copy link
Contributor Author

hsyhhssyy commented May 23, 2025

Perhaps we could look at adding an new option that disables automatic class-definition insertion when a new file is created. In many client-side editing scenarios, users don’t always save files in a package-style directory structure (as one might in Java), so this behavior isn’t always desirable.

One idea is to introduce a setting—perhaps called autoCreateName, enabled by default.
I outlined a similar need when I proposed autoAdjustName: our workspace often contains files intended for different environments (for customers that have on source control it is very common), which means their filenames won’t necessarily align with package names. Also, placing a single file deep inside a folder hierarchy can feel awkward.

If it seems like we’re introducing too many individual settings, we could consider streamlining autoAdjustName into a single option with three possible values— “no,” “create,” and “create, copy and move”—with “create” as the default. I have create another PR to implement this approach.

image

@hsyhhssyy
Copy link
Contributor Author

hsyhhssyy commented May 23, 2025

Based on my testing, the update in vscode-objectscript-3.0.3-dev.1562.vsix.zip seems to have resolved the Problem 2.

But I’m a bit concerned about whether relying on a timeout is truly reliable—particularly if my computer or disk happens to be unusually slow.

@isc-bsaviano
Copy link
Contributor

Thanks for checking the vsix @hsyhhssyy. I am not completely satisfied with the timeout as well, but I don't think there's a better way to do this because the extension can't "know" ahead of time that the file is supposed to have content. I will discuss your PR with the other maintainers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment