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

VSCode suggestions results in an extra "<" #67

Closed
AndrewTriesToCode opened this issue Jun 28, 2020 · 21 comments
Closed

VSCode suggestions results in an extra "<" #67

AndrewTriesToCode opened this issue Jun 28, 2020 · 21 comments

Comments

@AndrewTriesToCode
Copy link

In VSCode on MacOS when starting to add a new tag in a .csproj file I start by typing and when the suggestions are shown I hit enter to pick the right one. This result in two "<" at the start of the line rather than one.

For example <langver> gets autocompleted as <<langver> which is invalid syntax.

Thanks!

@tintoy
Copy link
Owner

tintoy commented Jun 28, 2020

Hi, thanks for reporting - I’ll see if I can reproduce this tomorrow morning :)

@tintoy
Copy link
Owner

tintoy commented Jun 29, 2020

Hmm, yep - I see the same behaviour. I guess they must have changed behaviour somewhere in the extension API 🙄

I'll try to get this fixed tomorrow morning (sorry, work's a bit crazy at the moment)!

@AndrewTriesToCode
Copy link
Author

@tintoy thanks! I know what you mean I have a semipopular open source library and a full-time job--hard to balance sometimes.

tintoy added a commit to tintoy/msbuild-project-tools-server that referenced this issue Jun 30, 2020
Slightly hacky mechanism for handling behavioural changes in the VSCode extension or LSP API where reported position no longer includes character that was typed to trigger completion (it's possible that this extension is not reporting some newly-defined capability or setting to VSCode that would enable it to see the previous behaviour but it's hard to tell given how often things seem to change).

NOTE: This set of changes is not exhaustive - it's just a record of the types of changes that need to be made more extensively.

tintoy/msbuild-project-tools-vscode#67
tintoy added a commit that referenced this issue Jun 30, 2020
Slightly hacky mechanism for handling behavioural changes in the VSCode extension or LSP API where reported position no longer includes character that was typed to trigger completion (it's possible that this extension is not reporting some newly-defined capability or setting to VSCode that would enable it to see the previous behaviour but it's hard to tell given how often things seem to change).

NOTE: This set of changes is not exhaustive - it's just a record of the types of changes that need to be made more extensively.

#67
@tintoy
Copy link
Owner

tintoy commented Jun 30, 2020

Ok, I can at least see a way to fix this, although it may take a while longer to work out why it has started happening. It seems that text positions (i.e. the insertion point) in LSP messages sent to our language service to request completions no longer include the position of the character that triggered completion (if there was one).

I suspect this is because newer versions of LSP actually include information about whether completion was triggered by a character (but we'd need to upgrade our LSP libraries and there are some pretty big incompatibilities on how those work these days - we were quite an early adopter and I've never had the time to upgrade given how disruptive it looked like it would be).

If these changes don't do the trick I guess I'll have to bite the bullet and do it the hard way ;-)

@tintoy
Copy link
Owner

tintoy commented Jul 2, 2020

Ok, I think I've got it working correctly now. Would you mind giving it a try by removing the extension and installing it from this VSIX package?

msbuild-project-tools-0.3.8.zip

@AndrewTriesToCode
Copy link
Author

@tintoy Thanks for the quick reply. I uninstalled and installed via the VSIX package. So it works if you select the first item, but if you arrow down and select another one it still adds the extra "<".

On another note, I most often use this with and it seems that it doesn't suggest this until well into typing it out--further than I would expect. Any viscose settings I should tweak related to that?

@tintoy
Copy link
Owner

tintoy commented Jul 2, 2020

That’s odd - I can’t reproduce that myself, would you mind turning up the log level for the extension and posting the log here? It should only be performing a single completion call.

@AndrewTriesToCode
Copy link
Author

Sure, I put the log on verbose and set a log file to ~/log.txt but I don't see a file there or anything in the output for MSBuild Project Tools window. If you can instruct me how to configure thatI'd be glad to.

To get the error I created a basic project with dotnet new mvc then I open up the .csproj file in vscode and in ItemGroups I type "<PackageRef" or how ever many characters I need to see it, then arrow down and select it, resulting in the extra starting character. I notice if I select the first option it always works fine, and often others are ok. Maybe this one is different because it has attributes like Include and Version? I had autosave on which really compounded the problem (omnisharp will try to repart the csproj file mid edit if I pause in typing), but I took it off to make things less difficult.

@tintoy
Copy link
Owner

tintoy commented Jul 2, 2020

PackageReference elements are a special case unfortunately :-/

Does it happen with consistently with any other element types?

@tintoy
Copy link
Owner

tintoy commented Jul 2, 2020

All you need to configure for logging in the VSCode settings JSON is:

{
   "msbuildProjectTools.logging.level": "Verbose"
}

Then you should see an output window pane called "MSBuild Project Tools":

image

@tintoy
Copy link
Owner

tintoy commented Jul 2, 2020

Ok, now it's happening for me but semi randomly. They really seem to have done something weird with the LSP behaviour. I'll let you know what I find.

@tintoy
Copy link
Owner

tintoy commented Jul 2, 2020

Righto, figured out the problem. I'll get it fixed and get a new build up for you to try as soon as I can :)

@AndrewTriesToCode
Copy link
Author

Awesome thanks. I was trying to get a good log capture for you but I couldn't made much sense of it all. Looking forward to the fix. Also for what it is worth another good test case is DotNetCliToolReference.

tintoy added a commit to tintoy/msbuild-project-tools-server that referenced this issue Jul 2, 2020
@tintoy
Copy link
Owner

tintoy commented Jul 2, 2020

Cool - hopefully this one will work:

msbuild-project-tools-0.3.8.zip

(the problem before was that I was only trying to handle the trigger characters when replacing an existing element, not when inserting a new one; so, you know, not the actual scenario you reported 😉)

@AndrewTriesToCode
Copy link
Author

AndrewTriesToCode commented Jul 2, 2020

Hm, now when I hit the trigger character my log shows this and I don't get any completions:

System.NullReferenceException: Object reference not set to an instance of an object.
   at async Task<CompletionList> MSBuildProjectTools.LanguageServer.CompletionProviders.CommentCompletion.ProvideCompletions(XmlLocation location, ProjectDocument projectDocument, string triggerCharacters, CancellationToken cancellationToken) in /Users/acw/Dev/defaultmvc/C:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer.Engine\CompletionProviders\CommentCompletion.cs:line 79
   at async Task<CompletionList> MSBuildProjectTools.LanguageServer.Handlers.CompletionHandler.OnCompletion(CompletionParams parameters, CancellationToken cancellationToken) in /Users/acw/Dev/defaultmvc/C:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer.Engine\Handlers\CompletionHandler.cs:line 202

tintoy added a commit to tintoy/msbuild-project-tools-server that referenced this issue Jul 2, 2020
tintoy added a commit that referenced this issue Jul 2, 2020
@tintoy
Copy link
Owner

tintoy commented Jul 2, 2020

☹️ 🤣

Ok, let's try that again:

msbuild-project-tools-0.3.8.zip

@tintoy
Copy link
Owner

tintoy commented Jul 2, 2020

(as you can see, that was a stupid copy-paste bug)

@AndrewTriesToCode
Copy link
Author

Perfect! I can appreciate a good copy-paste mistake. Appreciate the quick turn around on this.

@tintoy
Copy link
Owner

tintoy commented Jul 2, 2020

Great! Thanks again for trying it out - I’ll give it a full run-through tomorrow and then publish a new version in the gallery (given the size of the audience I’m paranoid about publishing without checking nothing else has been broken)...

@pm4rcin
Copy link
Contributor

pm4rcin commented Feb 8, 2022

@tintoy I guess it can also be closed. :)

@tintoy
Copy link
Owner

tintoy commented Feb 8, 2022

Thanks!

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

No branches or pull requests

3 participants