Re: [platform-core-dev] e4 Resources Kickoff Meeting

["James Blackburn" <jamesblackburn@xxxxxxxxx>]

Hi Serge,

> I'm not sure two different resources that point to the same physical
> location should share the same list of markers.
>
> For instance, if a file is shared in two different projects, but because of
> the projects settings (predefined symbols, for example) the file in project
> A builds fine while the same file in project B has build errors, it would be
> a mistake to show the file in project A as having the same errors as well.
>
> Does that makes sense?

I think it's tricky. As the file _really is_ the same file it seems
wrong that editors get out of whack, local history is different, etc.
Especially as Eclipse makes such efforts to keep multiple editors in
sync when they're pointed over the same IResource.

What prompted the moan was frustration when CDT error parser annotates
files in a 'non-CDT' contains-all project -- presumably because it
uses findFilesForLocation somewhere. Having fixed the errors, the next
build of your C project doesn't remove  the markers because the
Resources being built are different from the resources with the
markers...  I've had the same problem with code that opens the 'wrong'
editor for a given filesystem location.

I can see that there are some instances where you want the two
resources to be treated differently.  However in the vast majority of
cases I believe users would expect the same physical file to share the
same attributes -- wherever it's linked from.  This is the behaviour
you get in a text editor or IDE without the tight resource linkage
that Eclipse has.

In the example you gave, CDT could work exactly as it does now.  When
you perform a clean build or switch configuration, it clears all
markers before running the build. The result would be that the file
shows the markers present from the last build.  While this isn't
perfect it works out the box.  CDT could then be extended to create
different markers depending on what project or project configuration
being built.

A lot of the problems I've seen with linked resources seems to stem
from this.  Users don't understand:
 - Why they can open the file multiple times (without explicitly using
open 'new editor')?
 - Why the C editor has incorrect syntax highlighting when opened from
the contains-all project instead of through their C Project (easy to
do with ctrl-shift-R)?
 - Why sometimes when you open the file a second time you get a
"Resource out of sync... Press F5 to refresh..." when the file is open
successfully in a different editor?
 - Why the {debugger --substitute your plugin here} opens the 'wrong'
source file when a breakpoint is hit (or your plugin performs some
operation).

Education users used to text editors or VS solutions is tough.
Perhaps if all the existing code and integrations handled multiple
resource resolution properly there wouldn't be a problem... It would
seem that all the above would get better if the IResources were
unified under the hood, and few things (anything?) would break.
Integrations could always use additional attributes on markers to
disambiguate between the resource in multiple contexts...

Cheers,

James

>
> Serge Beauchamp.
> Freescale Semiconductor
>
> James Blackburn wrote:
>>>
>>> Then I'd like to walk through the wiki page, the Work Areas page that
>>> Martin
>>> O. has prepared and see if there anything people have objection to, or
>>> items
>>> they'd like to add. The wiki site is here:
>>> http://wiki.eclipse.org/E4/Resources please take a look before the
>>> meeting.
>>>
>>
>> One of the things that isn't on the list is how the Workspace
>> currently copes with multiple IResources which map to the same
>> filesystem Location.  These occur when you're building projects using
>> linked resources, or have created multiple projects with overlapping
>> locations.
>>
>> Currently Eclipse treats multiple workspace resources (with same
>> location) separately.  They open to separate editors, have separate
>> local histories, have separate markers, etc.  See:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247647 for the sorts of
>> things that go wrong.
>>
>> It seems very difficult if not impossible for ISVs to integrate
>> properly if the platform really gives you multiple IResources for a
>> given location (with findFilesForLocation()).  It certainly seems
>> non-trivial to decide on which File a marker should be created, or
>> which IFile should be opened when all you've got is the path provided
>> by an external tool.
>>
>> Am I naive in believing that if they really are the same file on disk,
>> they really should map to a single IResource (or multiple IResources
>> with the same set of attributes)?
>>
>> Cheers,
>>
>> James
>> _______________________________________________
>> platform-core-dev mailing list
>> platform-core-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
>>
>
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
>