Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 323673 - Override indicator is not shown when file is opened from CVS/git history
Summary: Override indicator is not shown when file is opened from CVS/git history
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-editor (show other bugs)
Version: 8.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-25 22:52 EDT by Andrew Gvozdev CLA
Modified: 2020-09-04 15:24 EDT (History)
5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Gvozdev CLA 2010-08-25 22:52:43 EDT 
With the fix from bug 323556 it is again possible to open C++ file from CVS/git history directly and syntax highlighting is working fine. But override indicator is not shown in that situation.
Comment 1 Marc-André Laperle CLA 2010-08-26 01:53:25 EDT 
Many features are not available like Outline, marking occurrences, hyperlinks, etc. This could be a more general problem. I tried opening a java file from the git history and the majority of the editor features worked.
Comment 2 Marc-André Laperle CLA 2010-09-04 00:42:17 EDT 
It seems JDT handles this by creating a "fake" compilation unit, see CompilationUnitDocumentProvider.createFakeCompiltationUnit. I have started porting the code blindly to CDT, I'm not sure how far I'll get.
Comment 3 Martin Oberhuber CLA 2011-05-16 10:56:19 EDT 
CQ:WIND00275014
Comment 4 Nathan Ridge CLA 2016-12-29 01:32:40 EST 
See also bug 483386, which is a similar request for semantic highlighting. I wrote some analysis in bug 483386 comment 2.(In reply to Marc-André Laperle from comment #2)
Comment 5 Nathan Ridge CLA 2016-12-29 01:33:47 EST 
(In reply to Marc-André Laperle from comment #2)
> It seems JDT handles this by creating a "fake" compilation unit, see
> CompilationUnitDocumentProvider.createFakeCompiltationUnit. I have started
> porting the code blindly to CDT, I'm not sure how far I'll get.

Do you have some work in progress to share, in case someone would like to pick this up?
Comment 6 Marc-André Laperle CLA 2017-01-03 11:46:40 EST 
(In reply to Nathan Ridge from comment #5)
> (In reply to Marc-André Laperle from comment #2)
> > It seems JDT handles this by creating a "fake" compilation unit, see
> > CompilationUnitDocumentProvider.createFakeCompiltationUnit. I have started
> > porting the code blindly to CDT, I'm not sure how far I'll get.
> 
> Do you have some work in progress to share, in case someone would like to
> pick this up?

Unfortunately, this was a long time ago and I don't have the work any more. But there was not that much value to it as it was mostly copy/pasted code from JDT with tons of unresolved errors. I think looking at CompilationUnitDocumentProvider.createFakeCompiltationUnit is still a valid place to start.