Closed ams-tschoening closed 5 years ago
I'm sorry to disappoint, but don't have any interest in supporting this. I would recommend either disabling the EditorConfig plugin when opening these legacy projects or take the time to convert the files to UTF-8.
Have I've been clear about that it's only about adding one line of text in your CHARSETS
-hash? It's not about any additional magic. So I need to wait until the EditorConfig-guys officially add additional encodings?
I still have some files encoded using
windows-1252
, which I can't easily convert toUTF-8
, because that is Perl with inline strings in the code sensible to encoding changes and stuff like that. Most of those files are heavily documented using German language with German umlauts etc., some are documented using English language using plain ASCII mostly and some use both.And here's the problem: While
windows-1252
isn't officially supported by EditorConfig, I put it into the file anyway because some plugins simply forward encoding stuff to the editor/IDE and let those handle that. Even if not, the file itself is the documentation what to use to do the right thing. Your plugin seems to simply ignore unsupported encodings and let Sublime Text decide, which is in general a good thing in my opinion: If a file is already encoded inwindows-1252
, Sublime Text detects that and keeps that encoding. The problem is if not, because Sublime Text than falls back toUTF-8
and if one then adds documentation using German umlauts, things get stored usingUTF-8
. Someone expecting all Perl files to bewindows-1252
then sees garbage.The easiest solution would simply be supporting
windows-1252
, as that is a pretty common encoding anyway and looking at your implementation should be somewhat easy. EditorConfig-guys are discussing this topic for years already, without any result.So what's your opinion?