Add editor encoding api #177434
Add editor encoding api #177434
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
Is there any chance to merge this PR? |
|
ping for merge |
Tarrowren
force-pushed
the
editor-encoding
branch
from
04cc224 to
fe87303
Compare
|
Is there any chance to merge this PR? |
|
Bump pull request |
|
We also asked for the very same thing and proposed to implement a PR like this here It would be really good to know if this has some possibility to be merged or if there is any other reason to not merge it. |
|
ping for merge |
src/vs/workbench/services/extensions/common/extensionsApiProposals.ts
Outdated
Show resolved
Hide resolved
Tarrowren
force-pushed
the
editor-encoding
branch
from
b8aef29 to
4b45369
Compare
|
Nice to see you still maintaining this pr. I hope someone will finally merge this soon. |
|
Is this PR actually blocked by anything meaningful or are we just waiting for the right persons to stumble upon it by chance? This PR is needed for full editorconfig support, which I would hope the entire vscode team agrees is a good feature (or rather, an embarassing one to say is incomplete). There's barely any content to review too, it looks so simple it's probably perfectly good to merge as-is. |
|
@bpasero could you please push this forward by merging or assigning to someone? This would finally implement full .editorconfig support for all the people waiting on it (which is a lot more than the handful who've bothered to find this issue and vote on it). Thanks |
|
Is this still relevant? |
Yes, very, lots of people are eagerly awaiting the merge |
|
@Tarrowren this change is heavily behind |
There was a problem hiding this comment.
@Tarrowren On a high level, the better location for encoding concerns is actually TextDocument. Because that maps to the underlying text model where the encoding information is at and where it can be changed. A text editor is never the owner of the documents encoding. This is the first change I am asking to do.
As for the API itself, encoding should be a readonly encoding: string that lives on TextDocument and can be received without awaiting a Promise. Subsequently, I would suggest a encode(encoding: string): Promise<void> and decode(encoding: string): Promise<void> method on TextDocument for the remainder.
Does that sound reasonable? Please let me know if you are willing to continue working on this PR given this feedback.
|
Thus this continues in #239961 |
see #824