Open ext-pierre-etchemaite opened 9 months ago
@ext-pierre-etchemaite , thank you for reporting this issue and the workaround.
Is it the lisp source code that can't be displayed correctly in the VS Code Editor? or file name / project name that can't be correctly displayed on the Project Panel on the left side?
If you don't mind, would you please send out a sample file that's in problem?
If it's in the Editor, the setting in the right-bottom cornor might help:
Click on it, and a list of encodings will show up at the top area for us to select or search for:
That's a capability of VS Code for us to manually override the encoding of the current document.
I can't post any complete file, but few relevant lines should suffice:
Problem concerns file content, not file names. And setting file encoding is exactly what I suggest to automate.
I just noticed that setting LISPSYS does not only determines what editor is launched, but also switches AutoLisp Unicode support, or AutoLisp Unicode source code support. So maybe that makes sense that this extension supports UTF-8 by default. (I'll have to investigate what values of LISPSYS I can safely use with that legacy code, but that's another story... The more I read LISPSYS description, the less I understand it, and what are the usecases of the different values)
I just noticed that setting LISPSYS does not only determines what editor is launched, but also switches AutoLisp Unicode support, or AutoLisp Unicode source code support. So maybe that makes sense that this extension supports UTF-8 by default. (I'll have to investigate what values of LISPSYS I can safely use with that legacy code, but that's another story... The more I read LISPSYS description, the less I understand it, and what are the usecases of the different values)
Yeah with LISPSYS=1, AutoCAD turns on the Unicode support for AutoLisp, and in this case, it invokes VS Code as the IDE, and VS Code will guess the encoding for each lisp file for rendering, because their encodings might be different.
With LISPSYS=0, AutoCAD provides the legacy behavior for AutoLisp.
If you work with lisp source files (.lsp) and don't need Unicode, both choices are fine.
If you work with compiled lisp files, like .fas, which were previously compiled by a legacy version of AutoCAD, or compiled by the latest AutoCAD with LISPSYS=0, then it's better to set LISPSYS=0 to keep compatibility.
@ext-pierre-etchemaite Thanks for your sample file. It should be a general issue with a Unicode supported software, as I opened the file and then got the same problem with Notepad, Chrome, etc. I think we'll have to live with the workarounds that we discussed above. It's a good idea to update the document for this issue and the solution. Thanks for your suggestion on this!
This extension forcing UTF-8 on all lisp files https://github.com/Autodesk-AutoCAD/AutoLispExt/blob/40011d18b5c9f6b4221ad1e89e3687c5437ac266/package.json#L276
And when you use AutoCAD's VLISP editor, it uses Windows-1252, therefore VSCode doesn't properly display saved by VLISP settings:
;|�Visual LISP� Format Options�
(100 4 1 2 nil "end of " 99 10 2 0 1 nil T nil T)
;*** DO NOT add text below the comment! ***|;
And next time you edit that file in VSLISP, it won't be able read the settings and will save default settings again:
;|�Visual LISP� Format Options�
(100 4 1 2 nil "end of " 99 10 2 0 1 nil T nil T)
;*** DO NOT add text below the comment! ***|;
;|«Visual LISP© Format Options»
(100 4 1 2 nil "end of " 99 10 2 0 1 nil T nil T)
;*** DO NOT add text below the comment! ***|;
Current solution is change encoding in VSCode settings:
@id:files.encoding @lang:autolisp
@id:files.encoding @lang:lisp
@id:files.encoding @lang:autolispdcl
I think this extension should not force file encoding at all. Let VSCode decide instead.
I had character set issues opening .lsp files from a non-english project, that displays correctly in VLIDE (and prompts display correctly in AutoCAD console too, of course). After some investigation, it seems the encoding used by those files, seldom mentionned as being "ANSI", is actually Windows 1252 encoding; And after some more investigation, I managed to make VS Code load those files correctly with some extra settings:
If my analysis is correct, and if it doesn't break anything, could the extension do that by default? Or at least document the problem and this possible solution.