Re: [platform-core-dev] Comments to "Marker Position Updates"

[Nick_Edgar@xxxxxxx]

Here are my comments:

- Marker updaters will need to be activated, which can lead to plugin 
activation earlier than you'd like.

- Core already introduces textmarker, so I don't see a problem in adding 
special support for text markers.
Will updates only be done on markers of type textmarker?  Can updaters 
only be registered on markers of type textmarker?
What happens if a marker type is not a subtype of textmarker, but still 
uses the CHAR_START, CHAR_END, LINE_NUMBER attributes?

- Offsets and size are specified as character offsets, rather than bytes. 
This corresponds to the attributes for textmarker, which are character 
based, but Core doesn't know how to convert files to text (doesn't know 
encoding). This is only an issue if it needs to read the file (e.g. the 
line number update problem).

- Why would special updaters be needed for problem, task, bookmark rather 
than just textmarker?

- Markers are not restricted to IFile - they can be on any IResource.  Or 
does textmarker only apply to IFiles?  Is it totally unreasonable for 
markers on other IResources to have positions?  Maybe so, but there is 
nowhere else in the markers API that states this AFAIK.

- As already pointed out, several marker updates may need to be done for a 
single file edit (e.g. deleting multiple selected methods).  These should 
be batched (transactional).  This is particularly problematic if the 
contents must be read (e.g. the line number update problem).

- Regarding the suggestion to make update diff-based, calculating a diff 
is expensive, requires access to the old and current content, and is lossy 
compared to tracking the individual edits (e.g. remove X then insert X may 
look unchanged in a diff, but markers in range should still be deleted). 
Finer-grained update commands seem necessary.

- Finally, this brings up the issue of how to handle transient marker 
changes in the workbench as a whole.  There was a post recently to 
platform-ui-dev suggesting that people think the task list gets out of 
date because it does not track the transient marker changes in the 
editors. It only updates their positions when the editor's contents are 
saved (marker creations and deletions show up right away though, and 
double-clicking on a task brings you to the right place in the editor). 
Also, other environments like Visual Studio show tasks for TODO comment 
tags in open editors, which we would have difficulty supporting with the 
current mechanisms since we don't have any notion of transient markers 
(other than what the text framework defines).
The old marker API (before opening marker types up) allowed markers to be 
modified without affecting the workspace.  E.g. an editor could get the 
markers for the file, modify their positions independently while the file 
was under edit, then commit the changes back to the workspace when the 
file was saved, or toss them out if the file was closed without saving.
It may be sufficient for the task list to track the marker annotation 
models for the open editors, but other clients (including headless 
clients) may face the same issues with transient markers.
Addressing this is more complicated than what the current proposal seeks 
to accomplish, but we should keep it in mind.

Nick