The plugin adds the annoying "someString" string.

[CodeLit]

Hello, can you please help me with the extension? This has been going on for a long time. The extension works great, but it has one annoying thing. Every time I paste some code via ctrl+v, it inserts "someString" where the variables were. It's really annoying. When I turn off the plugin in vscode, this doesn't happen. Appreciate for any help

Lua extensions enabled: vscode-glua-enhanced, vscode-glualint

[Goz3rr]

Which version of glualint are you using? You can check by running glualint --version in the vscode terminal

[CodeLit]

@Goz3rr 1.25.0

[Goz3rr]

I'm baffled to be honest, there isn't any logic that runs specifically on copy pasting. If you end the file with test2 and then run format document, does someString also appear?

Do you have any glualint configuration files that you're using? I cannot seem to reproduce this at all

[CodeLit]

Bare new project with no plugins enabled in vscode.

Yes, it's appearing on format, and also on paste. No config files enabled.

[CodeLit]

"glualint.activeLanguages": [
    "glua",
    "lua"
],

[robotboy655]

I can confirm this, it is coming from the pretty print feature (Format Selection command of VS Code), which the OP likely has set to automatically run on paste.

It is likely the bug is coming from glualint itself, not the extension. https://github.com/FPtje/GLuaFixer/blob/65535c144aeb00da27c9bbe479df59655a7eb242/src/GLua/Parser.hs#L353

@FPtje

[CodeLit]

Should I move this issue to that project? Or paste it as a reference?

[robotboy655]

Yeah, that would make sense.

It also happens on the web version as well (https://fptje.github.io/glualint-web/)

https://github.com/Goz3rr/vscode-glualint/assets/3299036/8632eddd-0c7d-44e7-a9ee-4c8580ff7dcc

[FPtje]

Here's what's happening: glualint has an error correcting parser. If you tell glualint to pretty print something that is syntactically invalid, it will take the shortest path in the parser to try to fix it. Usually, when you copy just a word, it adds "someString", because foo"someString" is syntactically valid Lua.

You can change this behavior with the setting prettyprint_rejectInvalidCode.

While admittedly the error correcting parser/pretty printer is a bit of a gimmick, I'm not sure what is expected from glualint here. It doesn't support working with invalid Lua, besides rejecting it or trying something silly to fix it.

I guess the solution here is to set above setting to true, or to not run glualint on typing.

[Goz3rr]

Ah, that explains why I couldn't reproduce it. I forgot i have a ~/.glualint.json file that has prettyprint_rejectInvalidCode set to true from testing another old bug.

It's a bit early in the morning, but as far as I know there I never added any logic to the extension to run the formatter on typing/saving. After a bit of searching I found out vscode has some built in settings: editor.formatOnSave, editor.formatOnType, and editor.formatOnPaste. You probably have the latter set to true which is causing this.

I'm also not entirely sure what would be the best solution here. By enabling the combination of editor.formatOnPaste without prettyprint_rejectInvalidCode you end up in this scenario.

[FPtje]

Hmm, if the extension has no knowledge of where it is called from (explicit format or from format on type), then I thi the most sensible solution is to either set that setting or disable format on paste and format on type.

[robotboy655]

I think latest changes to glualint itself make this issue resolved.

[FPtje]

Yeah, the correcting parser has been removed. That does mean it doesn't always format the code. Though I guess that is preferable over formatting syntactically invalid code and hallucinating random strings.

Glualint, hallucinating stuff before LLMs made it cool 😎

[Goz3rr]

Cool, I'll close this issue as well then