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.

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

Alloy XML autocompletion | suggestion issue #151

Open
jason919 opened this issue Nov 1, 2019 · 7 comments
Open

Alloy XML autocompletion | suggestion issue #151

jason919 opened this issue Nov 1, 2019 · 7 comments

Comments

@jason919
Copy link

jason919 commented Nov 1, 2019

I noticed that if the Alloy XML tag has many attributes inside XML, instead of inside tss, then when I hit "ctrl+space", the suggestion is just hanging in "Loading" state. If that happens, all other autocompletion in other XML tags will be hanging. The only way to get out of this is to restart VS code.

@ewanharris
Copy link
Collaborator

@jason919 Could you please provide a reproducible test case? Without one, this bug report is a timesink for us to figure out how many attributes "many attributes" is.

@jason919
Copy link
Author

jason919 commented Nov 4, 2019

This issue happens to any dummy project. For example, you can create a dummy project with a single index.xml. And replace it with below, then you can place your cursor at <ImageView tag, hit ctrl+space, you will see it hanging at "loading". Then you can try the ctrl+space on other Tags too. It seems like any Tag with 3 attributes will have a problem, anything with just 2 attributes is ok.

<Alloy>
	<Window class="container" width="15" height="19" right="20" top="10" backgroundColor="transparent" >
		<Label id="label" onClick="doClick">Hello, World</Label>
		<ListView id="listView" onItemclick="onSelectRow">
            <Templates>
                <ItemTemplate name="simple" backgroundColor="#fff" height="40" >
                    <View bindId="bgView" left="0" right="0" top="0" height="40">
                        <Label class="rowTitle"></Label>
                        <ImageView image="/img/icon/next.png" width="15" height="19" right="20" top="10" backgroundColor="transparent"></ImageView>
                        <View height="1" bottom="0" left="0" width="Ti.UI.FILL" backgroundColor="#e7f2f9"></View>
                    </View>
                </ItemTemplate>
            </Templates>
            <ListSection class="section">
                <ListItem title:text="{title}" title:sid="{sid}" bgView:backgroundColor="{bgColor}"></ListItem>
            </ListSection>
        </ListView>
	</Window>
</Alloy>

@jason919
Copy link
Author

jason919 commented Nov 4, 2019

As I mentioned, the problem is with having the attributes directly inside the XML tag, if i move those attributes to tss, it works fine. Is it possible that we can have a shortcut to move all the attributes to tss for a Tag automatically?
The reason I have those attributes inside XML tag directly is only for development, it is quicker to add.

@jason919
Copy link
Author

jason919 commented Nov 5, 2019

can anyone help point out where the code that manages the autocomplete for Alloy xml?
Maybe I can figure out the fix

@ewanharris
Copy link
Collaborator

@jason919 The provider logic lives under src/providers/ and then the providers for xml files start with view. I think ctrl+space is the keybinding for intellisense so you'd be looking for the corresponding completion provider.

I've tried reproducing what you're seeing. I think it's partially expected although I can't reproduce the hanging you describe and I'm making the presumption that you don't have an i18n directory.

What's happening is as you're triggering intellisense outside of the tag we're falling back to the default action of providing i18n completions, that function, only resolves if the app/i18n directory exists. I believe vscode is waiting for us to resolve and that's why it shows the loading state, if we fix that function to resolve with an empty array when the i18n directory doesn't exist then this should be fixed.

If you'd like to take this issue I'd be more than happy to help you in making the PR, just let me know!

@jason919
Copy link
Author

jason919 commented Nov 5, 2019

I added the i18n folder, it still didn't help.
I figured out the exact bug. for example, I have <View height="1" bottom="0" left="0" width="Ti.UI.FILL" backgroundColor="#e7f2f9" > if I place the cursor after backgroundColor, then the autocomplete suggestion doesn't work, but if I place the cursor right after the '<view ', then the suggestion works. so I think the issue is the parser logic in the completion provider.
I tried to output some debug statements in the extension by using console.log, it didn't work. Do you know how to write debug into the output pane ?

@ewanharris
Copy link
Collaborator

@jason919, did you create a i18n file with content? i.e. app/i18n/en/strings.xml. There's a few places where we need to resolve in the else case to fix this bug so creating the directory isn't enough

  1. the folder existence check
  2. file existence check
  3. file contents check

I think for the new case, you're hitting a design problem with the autocomplete setup where we generate Alloy tags based off the parsers directory in alloy, there isn't a parser for Ti.UI.View (it doesn't need one), but Ti.Map.View does have one, so that is what the <View> tag completion refers to. When we then look Ti.Map.View up against the SDK completions we only get the basic suggestions (it's technincally not an SDK type, it's a module) and not the Ti.UI.View suggestions. IMO, technically that is a separate issue to this one, and won't be as simple of a fix. We're currently working on a new mechanism for our intellisense so I'd prefer for us to fix it there than try to restructure our exiting implementation.

As for console.log-ing, the only log output we have today is for the builds and that's not really accessible in other places like the completion providers. I'm not that familiar with where vscode places those logs, maybe it's one of the Log outputs in the OUTPUT channel? If you are interested in making this change, I'd recommend directly debugging the extension (as shown in the contributing guide rather than dropping console.logs, as it'll be much easier to tackle under the debugger

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants