Re: [cdt-dev] bug #151005 - Error parser - cannot generate proper marker

[wieant@xxxxxxxxx (Wieant Nielander)]

> - If the error parser cannot create an IFile object for a given path
> then it attaches the problem marker to the project. That's why the file
> cannot be opened in a simple way from the problems view
> - A new marker type could be defined which has an additional attribute
> like "externalLocation" (derived from the standard C/C++ problem marker)
 ...
> Another drawback is that annotiations probably also won't work for the
> external file. I'll have to think about this some more, maybe we can
> configure the CEditors annotation access ...
> 
> Anyway I would like opinions on whether this is worth doing in spite of
> the drawbacks, or whether other, more elegant ways of doing this can be
> imagined.

Norbert,

We seem to have implemented a variant of your proposed solution for a
different filetype that also allows inclusion of external files. In case of
an error in an external file, the originating translationunit resource is
set in the error marker, the marker offset is set to 0, and some derived
marker attributes are added that refer to the external file and error
offset.

To solve the double-click problem the special marker is caught in the
'gotoMarker()' method of the source editor. So when the
external-file-marker is selected the original translationunit resource is
opened, catches the marker, sees it's for an external file, then also opens
an editor for the external file at the right position. Drawback ofcourse is
that the original TU resource is always opened besides the actual offender.

May not be the most elegant solution, but it seems to do the trick
(partially that is, the problem regarding annotations for the external file
still remains). I guess a more elegant solution would be to allow markers
to refer to external files.

Regards,
  Wieant