-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Formatter breaks hexBinary by inserting newline and spaces #1010
Comments
Have you tried to set to 0 (see doc at https://github.com/redhat-developer/vscode-xml/blob/main/docs/Formatting.md#xmlformatmaxlinewidth) |
I've seen this setting and I'm confident it could be a workaround. However, as far as I understand, this would also prevent all other content, like elements with regular, non-binary text content, to be formatted to fit the screen. Furthermore, the thought behind this report was more to have the formatter behave in a clever but conservative way by default so as to not cause trouble in its default configuration. I'd rather not rely on each developer editing XML files (probably on the fly without a dedicated workspace set up) that contain hexBinary elements to first go through the formatter configuration. |
You mean that you would like:
If it that I don't know how to do that,in XML Document long hexBinary data or text is considered as Text node. |
I understand. Would it be an option to try detecting "long hexBinary lines (something along the lines of |
No there is no option for this usecase. Do you know an xml formatter which does that? |
We've checked a couple of other XML formatters in this regard:
Inserting whitespace characters into hexBinary values like this by default caused us quite some trouble(shooting), so I thought it'd be nice if vscode-xml behaved better than other formatters by default, and since there are quite reliable ways to make it better I thought I'd give it a shot and open an issue. |
When we have an element containing long hexBinary data like this:
The formatter modifies it to become:
This however causes trouble down the line. Furthermore there's ultimately no real added benefit for breaking here since the resulting line cannot be further broken down and still doesn't fit into the maximum line length.
I didn't find an option to not break long single-word element content. I think such a configuration option should be considered and maybe even enabled by default.
The text was updated successfully, but these errors were encountered: