stevedlawrence commented on issue #165:
URL:
https://github.com/apache/daffodil-vscode/issues/165#issuecomment-1195808994
Note: I'm unassigning myself since I'm not actually working on this issue.
I'd prefer we use @ if you need to call someone's attention to an issue.
> Based on VS Code examples for autocompletion, the string method
"contains()" was used to return true or false to a string comparison of
possible XML components that were in the line where the autocomplete was
triggered.
This is the crux of the issue. For example, I can easily imagine an example
like this:
```xml
<xs:element name="foo"
dfdl:someProperty="bar"
|
```
Where we are autocompleting on the last line of this where the pipe
character is. The context of what is avialbale to autocomplete has nothing to
do with the line where the autocomplete was triggered. You need to inspect what
type of node were are actually in (i.e. element, group, sequence, etc.), which
is why I suggested something like `openItem` to figure out what the openItem is.
> One relatively easy way to provide an alternative to the hardcoded
namespace "xs" could be to use the JavaScript/TypeScript object "regExp" to
define a regex that compares '<' + any characters + "element"
Ideally one would inspect the current XML namespace scope to determine what
prefixes are mapped to to the XMLSchema namespace and then use those prefixes
determine the element. That's extra complication though, I think the hardcoded
prefix issue should be resolved as another issue, I was just showing one
example where this code might fail. Assuming the namespace prefix is `xs` is
probably reasonable for now, thought we are starting to move away from that.
> The entire document could also be parsed into XML components and
associated with positions and some method developed to query if a tag is open
by position, although thought would have to be given to how to handle inserting
attributes into already closed tags of existing schemas.
I agree that this adds extra difficulty, and probably isn't the best
solution especially from a performance perspective. We don't want to have to
parse the entire document everytime an character is inserted or we
autocomplete--this will be impossibly slow with large schemas. But this is sort
of the right idea I think. Rather than just looking at the first line, we look
back far enough to get a reasonable idea about what the context is. In some
cases that context will be on the same line, but often times it won't be. The
`openItem` function seems to do something like that. I think that would be a
happy medium of performance and accuracy of autocompletion context.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
