Skip to content
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.

Sign up for GitHub

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

Jump to bottom

compile/validate complete document; dont fail fast on first error #956

Open
goyalyashpal opened this issue Nov 30, 2023 · 4 comments
Open

compile/validate complete document; dont fail fast on first error #956

goyalyashpal opened this issue Nov 30, 2023 · 4 comments

Comments

@goyalyashpal
Copy link

title/summary:

compile/validate complete document; dont fail fast on first error

details:

  • currently, the xml extension (v0.26.1) shows only the very first error it encounters in the document.
  • which makes fixing procedure cognitively tedious - fix, wait, check, repeat.
  • it would be nice shows all errors together

Additional details:

screenrecording:

VSCodium_MTfRntLrDN.mp4

MWE:

<?xml version="1.0" encoding="UTF-8"?>

<!-- <!DOCTYPE html> -->
<!-- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> -->

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=80%, initial-scale=1.0"/>
    <title>HTML with XML</title>
</head>

<body>
    <p hidden>Attribute value validation</p>
    Entity validation: &
</body>

</html>
@angelozerr
Copy link
Contributor

It exists some discussion about this topic, see #947 (comment)

See too my suggestion at #947 (comment)

But please keep in mind that we don't control the error validation. We delegate XML validation to Xerces Java library.

@goyalyashpal
Copy link
Author

goyalyashpal commented Nov 30, 2023 •
edited
Loading

problem with this strategy [of not stopping on first] is that Xerces can reports a lot of errors which ... depends from the fatal error. Once the fatal error is fixed, the other errors could disapear.

... annoying because you could try to fix some errors [which appear] after the fatal error but the fix could not be corrected when you will fix the fatal error.

see [discussion at] #947 (comment) 1819062458

ahhhw, i see. one solution can be to proceed by applying the fix internally. ofc this'd work only if the fix at that place could atleast be semantically unambiguous. but seems it will be enough for covering a good range of common lints.

provide xml.validation.stopOnFatalError which could be set to true by default (to have the current behavior)

See too my suggestion at #947 (comment) 1819065943

yeah, that would make sense

We delegate XML validation to Xerces Java library.

[Xerces project] seems not be very activate.
#947 (comment) 1817538752

The Apache Xerces™ Project https://xerces.apache.org/

The Apache Xerces™ Project uses Subversion (SVN) as version control tool.
https://xerces.apache.org/repo.html

aaahhhh the Apache....

@goyalyashpal
Copy link
Author

provide xml.validation.stopOnFatalError

the better one can be xml.validation.forceCompletion as this somewhat better indicates what the setting would do...

one solution can be to proceed by applying the fix internally

one more +ve point i think: this would very much suffice for the syntactic errors, i.e. those unrelated with DTD grammar. as the XML's syntax is pretty unambiguous & deterministic as far as i know.

Xerces can reports a lot of errors which ... depends from the fatal error. Once the fatal error is fixed, the other errors could disapear

i just tried and recalled, that this happens all the times in other languages too (python, markdown, java etc). say for example when entering a string or a comment with ending delimiter not entered yet - a good chunk of following part turns squiggly. or in other such instances.... but these all show all the errors regardless.

one recent example with markdown:

VSCodium_mkS55HyJbZ.mp4

source:

[node]: https://stackoverflow.com
[node shebang]: https://stackoverflow.com
[qjs]: https://stackoverflow.com

[phantomjs]: https://stackoverflow.com
[firefox -headless]: https://stackoverflow.com

[jjs]: https://stackoverflow.com
[rhino]: https://stackoverflow.com
[ipython]: https://stackoverflow.com

[csript]: https://stackoverflow.com
[jsc]: https://stackoverflow.com


[node]: 
[node shebang]: 
[qjs]: 
[phantomjs]: 
[firefox -headless]: 
[jjs]: 
[rhino]: 
[ipython]: 
[csript]: 
[jsc]:

@angelozerr
Copy link
Contributor

xml.validation.forceCompletion

I find the name is ambigous because there is completion which can mean auto completion.

but these all show all the errors regardless.

It is working because the parser of those language are fault tolerant. We did that too for other language like with our Quarkus Qute parser. Xerces is not fault tolerant and we dont want to re implement an XML validation which is an hatd work even if intern1lly we h1ve implemented a fault tolerant parser for XML to support for instance completion foldings hypelink etc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@angelozerr @goyalyashpal