Skip to main content



      Home
Home » Eclipse Projects » Eclipse Platform » Markers - Tracking reliability and customization
Markers - Tracking reliability and customization [message #319995] Fri, 07 September 2007 12:58 Go to next message
Eclipse UserFriend
Originally posted by: eclipsenews-9999-exp.sblk.de

Hi,

[Abstract]
I have some questions concerning the internal handling of markers and
the updating of their positions as well as the degree of influence which
the current API provides.

[Context]
I am currently working on a copy&paste clone tracking plugin for
Eclipse. One of the main requirements for such a plugin is a reliable
way of tracking ranges in files over all kinds of edits.
At first sight markers seem to be exactly what would be needed to
accomplish this. However, unfortunately the documentation is very
limited when it comes to specifying the exact behaviour and the kinds of
guarantees given in terms of tracking reliability.

[Problem]
Reading older entries on this newsgroup as well as marker related bug
tracker entries, it seems that the current marker implementation may not
be robust and flexible enough for such an endeavour.

[Questions]
1) How reliable is the current position tracking for markers? Is a once
set marker correctly updated over all common edit actions? Refactorings?
Source Reformats? Reverting a file? Using the local history? Undo/Redo?
Move/Rename/Delete of resources? (Our application would be limited to
the java editor only)
There are a couple of open bug reports on the tracker which do not
promote confidence in the robustness of the current implementation, i.e.:
* [rulers] Markers disappear from editor on external change/refresh local
https://bugs.eclipse.org/bugs/show_bug.cgi?id=35696

2) Currently markers are mainly used to store only a small amount of
data per file. Would the current implementation be able to cope with
TEXT markers in ranges of 50 to 1000 per file? In a large project? How
would this affect overall performance?

3) The degree of influence on marker position updating seems to be
limited. Is there any way to provide a custom strategy for the handling
of position updates? Something like IPositionUpdater. As far as I
understand IMarkerUpdater, it does not provide any way to do this. What
I'd need is a way to implement special semantics for changes which
overlap with a markers range. It wouldn't be possible to fix this "after
the fact" in an IMarkerUpdater as I'd need to obtain something similar
to a DocumentEvent. These semantics would also need to be applied on
changes which don't happen in an editor, i.e. Refactorings.
* [resources] Refresh from local doesn't consider markers (1G83QOY)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=3551
Reads as if this is not possible and not even planned, is that correct?
also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=137331

4) Assuming that markers are not fit for this purpose, as seems to be
the case. If positions are tracked by adding Positions to each open
document, providing a custom IPositionUpdater or by directly subscribing
to IDocument changes and are stored in my own storage.
Is there any way to hook code into modifications which happen without
opening an editor? Like refactorings or source reformats? Or would I
need to listen to ResourceChange events and manually calculate the
differences?
And are Positions in an open editor automatically updated correctly on
undo/redo actions or reverts of a file?

I'd be very grateful for some pointers. I wasn't really able to figure
out these issues from the documentation so far.
Thanks a lot.

Greetings
H. Meyer

PS: A somewhat unrelated last question - is anyone aware of an existing
plugin which also requires long term tracking of positions inside of
source files? Maybe someone has already solved some of these problems. :|
Re: Markers - Tracking reliability and customization [message #320138 is a reply to message #319995] Wed, 12 September 2007 08:42 Go to previous messageGo to next message
Eclipse UserFriend
H. Meyer wrote:

>Hi,
>
>[Abstract]
>I have some questions concerning the internal handling of markers and
>the updating of their positions as well as the degree of influence which
>the current API provides.
>
>[Context]
>I am currently working on a copy&paste clone tracking plugin for
>Eclipse. One of the main requirements for such a plugin is a reliable
>way of tracking ranges in files over all kinds of edits.
>At first sight markers seem to be exactly what would be needed to
>accomplish this. However, unfortunately the documentation is very
>limited when it comes to specifying the exact behaviour and the kinds of
>guarantees given in terms of tracking reliability.
>
>[Problem]
>Reading older entries on this newsgroup as well as marker related bug
>tracker entries, it seems that the current marker implementation may not
>be robust and flexible enough for such an endeavour.
>
>[Questions]
>1) How reliable is the current position tracking for markers? Is a once
>set marker correctly updated over all common edit actions? Refactorings?
>Source Reformats? Reverting a file? Using the local history? Undo/Redo?
>Move/Rename/Delete of resources? (Our application would be limited to
>the java editor only)
>
>
There's no built-in concept of markers always being up to date: anyone
can change a file and there's no guarantee that this client correctly
updates the attached markers.

>There are a couple of open bug reports on the tracker which do not
>promote confidence in the robustness of the current implementation, i.e.:
>* [rulers] Markers disappear from editor on external change/refresh local
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=35696
>
>2) Currently markers are mainly used to store only a small amount of
>data per file. Would the current implementation be able to cope with
>TEXT markers in ranges of 50 to 1000 per file? In a large project? How
>would this affect overall performance?
>
>3) The degree of influence on marker position updating seems to be
>limited. Is there any way to provide a custom strategy for the handling
>of position updates? Something like IPositionUpdater. As far as I
>understand IMarkerUpdater, it does not provide any way to do this
>
It does but only for markers that are edited within a textual editor.

>. What
>I'd need is a way to implement special semantics for changes which
>overlap with a markers range. It wouldn't be possible to fix this "after
>the fact" in an IMarkerUpdater as I'd need to obtain something similar
>to a DocumentEvent. These semantics would also need to be applied on
>changes which don't happen in an editor, i.e. Refactorings.
>* [resources] Refresh from local doesn't consider markers (1G83QOY)
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=3551
>Reads as if this is not possible and not even planned, is that correct?
>also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=137331
>
>4) Assuming that markers are not fit for this purpose, as seems to be
>the case. If positions are tracked by adding Positions to each open
>document, providing a custom IPositionUpdater or by directly subscribing
>to IDocument changes and are stored in my own storage.
>Is there any way to hook code into modifications which happen without
>opening an editor?
>
Take a look at the file buffers plug-in.

Dani

> Like refactorings or source reformats? Or would I
>need to listen to ResourceChange events and manually calculate the
>differences?
>And are Positions in an open editor automatically updated correctly on
>undo/redo actions or reverts of a file?
>
>I'd be very grateful for some pointers. I wasn't really able to figure
>out these issues from the documentation so far.
>Thanks a lot.
>
>Greetings
>H. Meyer
>
>PS: A somewhat unrelated last question - is anyone aware of an existing
>plugin which also requires long term tracking of positions inside of
>source files? Maybe someone has already solved some of these problems. :|
>
>
Re: Markers - Tracking reliability and customization [message #320674 is a reply to message #320138] Wed, 26 September 2007 13:22 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: eclipsenews-9999-exp.sblk.de

Daniel Megert wrote:
> There's no built-in concept of markers always being up to date: anyone
> can change a file and there's no guarantee that this client correctly
> updates the attached markers.

However, I take it that as long as a file modification is done through
Eclipse by code which uses FileBuffers.getTextFileBufferManager()
instead of direct IO on the file itself, all markers should be correctly
updated?

>> 3) The degree of influence on marker position updating seems to be
>> limited. Is there any way to provide a custom strategy for the handling
>> of position updates? Something like IPositionUpdater. As far as I
>> understand IMarkerUpdater, it does not provide any way to do this
>
> It does but only for markers that are edited within a textual editor.

And how would that be done? IIRC IMarkerUpdater.updateMarker(...) is
called after the marker position was updated and the document event
which caused the update is no longer available, or am I wrong?
Or is there a special category for which an IPositionUpdater should be
registered?

>> ... If positions are tracked by adding Positions to each open
>> document, providing a custom IPositionUpdater or by directly subscribing
>> to IDocument changes and are stored in my own storage.
>> Is there any way to hook code into modifications which happen without
>> opening an editor?
>
> Take a look at the file buffers plug-in.

That was the right pointer, thanks a lot :o)

If anyone else also needs to do this:
I gave up on Markers/IMarkerUpdaters and am now working with
Positions/IPositionUpdaters and my own storage system.
I am registering an IFileBufferListener and using its
bufferCreated(IFileBuffer) method to get am IDocument handle (from the
IFileBuffer after casting it to ITextFileBuffer). I can then register my
own position category and a corresponding IPositionUpdater with the
IDocument.
And I am cleaning up everything in bufferDisposed(IFileBuffer).
This works well for edits in editors and for background edits like
source reformats or refactorings.


One other question:
Is there any way to integrate an IPositionUpdater with the undo/redo
actions of the corresponding editor?
I.e. an undo action will generate a new DocumenEvent and the
IPositionUpdater will be called again. However, the original
DocumentEvent (the one which is now being undone) may have deleted some
positions, which will not be restored correctly if the
"undo-DocumentEvent" is processed normally.

The same goes for a "Revert" action. It creates a DocumentEvent which
replaces the entire document content and thus removes all positions.

I've been able to work around the revert issue, though not in a nice
way. But the undo/redo part still poses a real problem.

Thanks a lot.

Greetings
H. Meyer
Re: Markers - Tracking reliability and customization [message #320703 is a reply to message #320674] Thu, 27 September 2007 11:40 Go to previous messageGo to next message
Eclipse UserFriend
H. Meyer wrote:

>Daniel Megert wrote:
>
>
>>There's no built-in concept of markers always being up to date: anyone
>>can change a file and there's no guarantee that this client correctly
>>updates the attached markers.
>>
>>
>
>However, I take it that as long as a file modification is done through
>Eclipse by code which uses FileBuffers.getTextFileBufferManager()
>instead of direct IO on the file itself, all markers should be correctly
>updated?
>
>
No. File buffers itself don't update the markers. It depends on whether
the client does it as there can be any kind of marker being attached to
the file.

>
>
>>>3) The degree of influence on marker position updating seems to be
>>>limited. Is there any way to provide a custom strategy for the handling
>>>of position updates? Something like IPositionUpdater. As far as I
>>>understand IMarkerUpdater, it does not provide any way to do this
>>>
>>>
>>It does but only for markers that are edited within a textual editor.
>>
>>
>
>And how would that be done?
>
You mean how the editor updates its markers? Take a look at
org.eclipse.ui.texteditor.ResourceMarkerAnnotationModel.

Dani

> IIRC IMarkerUpdater.updateMarker(...) is
>called after the marker position was updated and the document event
>which caused the update is no longer available, or am I wrong?
>Or is there a special category for which an IPositionUpdater should be
>registered?
>
>
>
>>>... If positions are tracked by adding Positions to each open
>>>document, providing a custom IPositionUpdater or by directly subscribing
>>>to IDocument changes and are stored in my own storage.
>>>Is there any way to hook code into modifications which happen without
>>>opening an editor?
>>>
>>>
>>Take a look at the file buffers plug-in.
>>
>>
>
>That was the right pointer, thanks a lot :o)
>
>If anyone else also needs to do this:
>I gave up on Markers/IMarkerUpdaters and am now working with
>Positions/IPositionUpdaters and my own storage system.
>I am registering an IFileBufferListener and using its
>bufferCreated(IFileBuffer) method to get am IDocument handle (from the
>IFileBuffer after casting it to ITextFileBuffer). I can then register my
>own position category and a corresponding IPositionUpdater with the
>IDocument.
>And I am cleaning up everything in bufferDisposed(IFileBuffer).
>This works well for edits in editors and for background edits like
>source reformats or refactorings.
>
>
>One other question:
>Is there any way to integrate an IPositionUpdater with the undo/redo
>actions of the corresponding editor?
>I.e. an undo action will generate a new DocumenEvent and the
>IPositionUpdater will be called again. However, the original
>DocumentEvent (the one which is now being undone) may have deleted some
>positions, which will not be restored correctly if the
>"undo-DocumentEvent" is processed normally.
>
>The same goes for a "Revert" action. It creates a DocumentEvent which
>replaces the entire document content and thus removes all positions.
>
>I've been able to work around the revert issue, though not in a nice
>way. But the undo/redo part still poses a real problem.
>
>Thanks a lot.
>
>Greetings
>H. Meyer
>
>
Re: Markers - Tracking reliability and customization [message #320760 is a reply to message #320703] Sun, 30 September 2007 11:43 Go to previous message
Eclipse UserFriend
Originally posted by: eclipsenews-9999-exp.sblk.de

Daniel Megert wrote:
> You mean how the editor updates its markers? Take a look at
> org.eclipse.ui.texteditor.ResourceMarkerAnnotationModel.

Thanks, I'll look into it.

Do you maybe also have any pointers concerning the positions undo issue
(see below)?

>> One other question:
>> Is there any way to integrate an IPositionUpdater with the undo/redo
>> actions of the corresponding editor?
>> I.e. an undo action will generate a new DocumenEvent and the
>> IPositionUpdater will be called again. However, the original
>> DocumentEvent (the one which is now being undone) may have deleted some
>> positions, which will not be restored correctly if the
>> "undo-DocumentEvent" is processed normally.
>>
>> The same goes for a "Revert" action. It creates a DocumentEvent which
>> replaces the entire document content and thus removes all positions.
>>
>> I've been able to work around the revert issue, though not in a nice
>> way. But the undo/redo part still poses a real problem.

Greetings
H. Meyer
Previous Topic:Testing product update and platform.xml changes
Next Topic:Eclipse misbehave ran using nonroot account but with root all is OK
Goto Forum:
  


Current Time: Tue May 13 10:12:51 EDT 2025

Powered by FUDForum. Page generated in 0.03671 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top