Summary: | [I18N] Annotation problem markers require strings externalized | ||
---|---|---|---|
Product: | [Tools] CDT | Reporter: | John Camelon <john.camelon> |
Component: | cdt-parser | Assignee: | Andrew Niefer <aniefer> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | P1 | ||
Version: | 2.0 | ||
Target Milestone: | 2.0 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
John Camelon
2004-05-19 11:50:53 EDT
I think most of the IProblem strings are already externalized in internal.core.parser/ParserMessages.properties. I do have other strings that need to be externalized though > W/the work Andrew is doing on adding IProblem annotations to the editor, we
> need to make IProblem internationalizable.
Sigh .. it is already started and can be enable(see work in progress).
Please see PR 61603.
I did not commit the rest yet. Since any way the parser
does not return any error, i.e. I got a second patch
removeing the reparse(A la JDT). Since C parsing is much
more cumbersome then Java.
Andrew's work is not the same as what you are doing ... Andrew's work comes from the Indexer and serves as a mechanism for users to see if there are semantic problems coming from the parse. You will not get these type of answers from QUICK_PARSE. Perhaps we should have a quick phone call this afternoon to make sure we are on the same page? > Perhaps we should have a quick phone call this afternoon to make sure we are
> on the same page?
Sure sounds cool.
But if you tell me that we are not overlapping, that's enough
for me.
My stuff is putting IMarkers on the resources as we index them. Currently I'm only marking preprocessor errors (includes etc), but I think the eventual idea was to have like the JDT compiler options to ignore or mark different problems as warnings/errors. The is potential overlap using structural parse if you open a file that has been marked with indexer errors, then once alain's code is triggered you will have both the index marking and the annotation marking. Using markers mean the problems show up in the problems view and (I think) allow for quick fixes in the future. I don't think the TranslationUnitAnnotationModel would support that. > The is potential overlap using structural parse if you open a file that has
> been marked with indexer errors, then once alain's code is triggered you will
> have both the index marking and the annotation marking.
For now, I do not generate IMarker on the annotation column of the CEditor
but only squiggly lines were the problem is trigger.
I reserved the IMarkers for "QuickFixes" i.e. problem that
I know I can provide a fix for .... Obviously we will
not have this tomorrow (next generation of the parser 8-).
The Annotation/Marker is actually transient meaning
once you close the Editor they disappear ... AND they
work on the working copy of the CEditor i.e. they piggy pack
on the reconciler thread to generate errors as the user is typing.
Well .. it is not exactly like that, the code was lifted from JDT
where they do a full reparse to get the IProblems(see
CompilationUnitProblemFinder). This will be to expensive for the
CDT, I'm planning to get rid of the TranslationUnitProblemFinder
to reuse the same parse pass as the outliner.
For now if you enable this, only scanner problems will show
as squiggly underlines:
#iffff
#endif
Enable in C/C++ working in progress.
|