Bug 4877 - Syntax highlight/code completion should ignore files not marked as 'Compile'
Summary: Syntax highlight/code completion should ignore files not marked as 'Compile'
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: C# Binding ()
Version: Trunk
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Mike Krüger
URL:
Depends on:
Blocks:
 
Reported: 2012-05-04 06:00 UTC by Alan McGovern
Modified: 2012-05-05 06:33 UTC (History)
1 user (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Alan McGovern 2012-05-04 06:00:09 UTC
This is a debatable change, but I think that if there is a .cs file which is not marked as 'Compile', it should not be treated as code. It will not be part of the build process so it doesn't make sense to treat it as code for highlighting or code completion purposes.
Comment 1 Mike Krüger 2012-05-04 09:58:12 UTC
I thought about that and atm it seems a good change.

Mostly because that's a good feedback for the user to see if a file is not compileable.
Comment 2 Mikayla Hutchinson [MSFT] 2012-05-04 12:00:30 UTC
AFAICT the way this is implemented, it'll break completion and outlining for files that are not directly compiled into the project, e.g. xml, aspx, etc
Comment 3 Mike Krüger 2012-05-04 12:34:05 UTC
no it works for xml etc. why should it break anything ? It's just blocking type system generation - and xml shouldn't do that.

Aspx shouldn't do that too, aspx should do an own handling of completion. TypeSystem parsing should only be done for real c#, vb.net etc. files.
Comment 4 Mikayla Hutchinson [MSFT] 2012-05-04 13:24:10 UTC
I checked. This breaks xml and aspx files at the very least, probably T4 too.
* document outline is empty
* folding doesn't update after loading
* code completion in aspx files throws an error
* inferred completion in xml files is broken

They all rely on OnParsedDocumentUpdated. And it seems reasonable for the Document class to keep an up-to-date ParsedDocument, instead of every completion extension having to re-implement it.

What we really need to do is not to disable the parse, but disable inserting it into the completion DB, and disable the C# semantic highlighting.
Comment 5 Mike Krüger 2012-05-04 14:01:39 UTC
code completion can't not work or not work depending on language -  makes no sense then.

But just disable the semantic highlighting does that make sense ? With the completion DB it's right - that's an error.
Comment 6 Mike Krüger 2012-05-04 14:02:08 UTC
btw. outline shouldn't be done with building a type system.
Comment 7 Mike Krüger 2012-05-04 14:02:19 UTC
same applies for breadcrumb.
Comment 8 Mikayla Hutchinson [MSFT] 2012-05-04 15:28:36 UTC
Parsing the open document is done for two main purposes:
1) To update the project type context
2) To have an AST of the current file

You're correct that only the C# files with the Compile build action need #1. But ~all files that have parsers need #2, for various reasons, which include outlining, folding, and code completion.

IME we need to separate #1 from #2. They should use the same parse (for performance), but the decision of whether to insert them into the project type context needs to be delegated to something else - some kind of ShouldInsertIntoProjectContext(ProjectFile file). This can also be used for checking whether to background parse files that are not open.

The reason I suggested explicitly disabling semantic highlighting for non-Compile files is that it doesn't make sense (and may not work correctly) if the file isn't part of the project type context.
Comment 9 Mike Krüger 2012-05-04 17:20:46 UTC
completion may even not make sense - or work correctly if it's not part of the project. At least for c# it's true.
Comment 10 Mikayla Hutchinson [MSFT] 2012-05-04 18:05:36 UTC
Well, sure, but that's the same for standalone C# files.

And it's certainly not true for XML, T4, aspx, etc.
Comment 11 Mike Krüger 2012-05-05 06:33:48 UTC
ok then it's not possible to do it, I now just disable semantic highlighting for them ... even if I don't know if that's a good idea.