Vscode: Provide encoding-related APIs for editor extensions
Currently there are only two fields in the TextEditorOptions API, a few other TextEditor-related APIs, and none of them is able to deal with the text buffer's encoding.
Comparing to Atom's TextEdit API, that is far from enough.
Most importantly, the API limitation makes it (seems) impossible for vscode-editorconfig to implement features like charset support, which is a crucial need for many people.
sodatea
All 34 comments
:+1: Also trimTrailingWhitespaces is missing
alexdima
on 30 Nov 2015
751 and #844 would probably be helped by this as well.
At least #751 would be solvable if working with BOM were better and my issues would completely go away if there was a way to, per editor extension, set the encoding and other stuff.
So :+1:
kmpm
on 1 Dec 2015
We also need access to the end of line sequence for EditorConfig.
jedmao
on 8 Feb 2016
- [ ] set/get encoding
- [ ] set/get charset
jrieken
on 29 Apr 2016
T_T... my extension ......
iHuahua
on 15 Jun 2016
still backlog... :(
buzzzzer
on 2 Sep 2016
I also need this for my extension, as I explain here. Did not realize this issue already existed.
Definitely want this feature!
Dickurt
on 8 Sep 2016
I believe that full .editorconfig support is blocked (https://github.com/editorconfig/editorconfig-vscode/issues/35) until the API for buffer encoding is added. Is there any chance this fact could speed this up?
tomasiser
on 4 Dec 2016
@tomasiser is correct. This is the last feature for full EditorConfig support.
jedmao
on 9 Apr 2017
any news?
afucher
on 3 Oct 2017
any news?
irudoy
on 4 Oct 2017
any news?
takekazuomi
on 9 Dec 2017
any news?
pixelhuh
on 9 Dec 2017
Does this issue have any chance to be resolved ?
I didn't find a way to work with a multi-encoding project (git repository), someone can help ?
bizoo
on 12 Feb 2018
any news? As @bizoo said, my multi-encoding project (git repository) will get problem in git diff view.
chongchai
on 9 Mar 2018
please say this is coming soon?
gingerbeardman
on 1 Apr 2018
This will be implemented after the Half-Life 3 release, I think 馃
irudoy
on 1 Apr 2018
Why does there seem to be so little interest in implementing this into the API? I don't believe it should be too difficult to do.
brainz80
on 20 Apr 2018
How is this issue handled? I See it's in the backlog but very far down. How are issues handled from the backlog? Could this perhaps be bumped up?
brainz80
on 5 Jun 2018
There are much more important features that should be implemented. For example, in May, it was done:
- [x] Explore improved positioning of the debug toolbar #2513 (WOW)
- [x] Recommend language packs based on the locale of the OS #45663 (AMAZING)
- [x] Custom view API enhancements: Support to listen the expand/collapse state #30535 (such a collapse API, BOOM)
- [x] Cosmetic changes to issue reporter #49579 (馃槺)
Encoding-related issues have low priority, because they are related to text editing. As you might guess, text editing is not important for a text editor.
irudoy
on 5 Jun 2018
:rage4:
AGraber
on 10 Jul 2018
@bpasero, @jrieken Care to take a look at this?
This issue was brought up by @sodatea (his comment) on November of 2015 and a similar issue seems to be reported here #34 from February of 2017. It would be nice if you could provide any explanation / "definitive no" if implementing these aren't possible -- my understanding is that you guys should be familiar with the API.
This issue has forced me to use other editors instead (Atom, Sublime Text) - in my work I have to constantly switch between files with different encodings and line-endings. Without editorconfig this would most likely end in a disaster.
brainz80
on 12 Oct 2018
@joaomoreno @bpasero @jrieken this issue is blocking phpcs 'PHP CodeSniffer for Visual Studio Code' from being used to its full potential. Any change to consider resolving this issue in order to attract more php coders to using VScode ?
mi-hol
on 14 Feb 2019
With access to 'encoding' of file, the diff gutter of GIT and SVN can improved (when files.autoGuessEncoding is true)
edgardmessias
on 18 Mar 2019
@joaomoreno @bpasero @jrieken this issue keeps being unresolved. Would be nice if you guys at least had a shout here. So we'd know we're not just barking at trees
brainz80
on 26 Mar 2019
Woof woof woof
(one for each year this bug has been alive)
gingerbeardman
on 26 Mar 2019
@alexandrudima I see you're a dev of VS Code. Could you shed some light on this matter?
brainz80
on 3 Apr 2019
For me it would be great to have at least get_encoding(), unlike set_encoding() it should be much easier to implement.
mechatroner
on 19 May 2019
please support multi charset
codecor-cn
on 23 Sep 2019
any news on this?
csaar95
on 25 Feb 2020
Any news here?
KUGA2
on 14 Oct 2020
5 years!?
gingerbeardman
on 14 Oct 2020
This is needed!
Similar to
vscode.window.activeTextEditor.document.eol
something like
vscode.window.activeTextEditor.document.encoding
is needed and I can imagine multiple use cases.
In my case (some own extension) I want to process a VSCode document's content with some external processing tool.
That tool must for sure be aware of the encoding to do a good job.
Thank you,
Jamil
jamilraichouni
on 11 Nov 2020
5 years!?
gingerbeardman
on 13 Nov 2020
Related issues
biij5698
路
3Comments
chrisdias
路
3Comments
trstringer
路
3Comments
lukehoban
路
3Comments
shanalikhan
路
3Comments
Most helpful comment
There are much more important features that should be implemented. For example, in May, it was done:
Encoding-related issues have low priority, because they are related to text editing. As you might guess, text editing is not important for a text editor.