[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] Re: New marker update API
|
Many of these questions are due to poor wording of the first draft. I have
added a "motivation" section to the draft that describes the problem a bit
better. Also see <JA></JA> responses below. I'm omiting issues that were
addressed in response to Jeff's post. Thanks to everyone for the feedback
so far, I'm learning a lot about how to (and how not to) write an RFC!
It seems the primary purpose of this is "convenience" api to allow an
editor (likely a text based editor) to adjust the location information of
all markers in the file using one operation. This feels wrong and opens
the door to a number of complications
<JA>This is not convenience API. Two problems are, 1) many components
modify files, and we need the update code in a central place. 2) Different
markers may require different update algorithms. There is a need to
de-couple the components that define the markers and know how to update
them, and the components that modify the files.</JA>
------------------------------------------
* Optimistically one could assume the updater is contributed by the
plugin doing the editing, but then this argues the facility is overkill &
the editor could just have a util class do it (see below).
<JA>This is not always the case, and it is not just editors that need to
modify files.</JA>
------------------------------------------
* Are there cases where the "way to update" is actually dependent on
the context the marker appears and not just a statically registered marker
updater? If yes then the marker update does not help this case (especially
since only one marker updater can be registered per marker type).
<JA>Kai has told me that marker update may depend on context, but I'm not
familiar with the exact cases. If the marker updater code needs to access
more context information, it could possibly access that information via
existing APIs (such as the JDOM). It is also possible that the update API
needs a more general definition, possibly including an IAdaptable object
from which the update code could query additional context information.
This is tricky though... the code doing the modification might not know
what context the marker update algorithm needs.
While how context information is obtained is an open question, I still
believe that a single update algorithm for each marker type should be
sufficient.</JA>
------------------------------------------
* There appears to already be existing api (setAttribute) that the
editor could call to adjust the markers & it's trivial for the editor to
make its own utility class if it needs to share that code.
<JA>Again, the code may not be trivial, and it's not just editors that need
to do this. Non-UI pieces may also manipulate files and hope to keep
markers up to date.</JA>
------------------------------------------
* Editors would likely not want to call this after each character
but instead would need to do it at "quiet" typing points. Unfortunately the
API doesn't give away any hint that it might not be advised to do it on
each character. That's the danger of convenience - it hides the work.
<JA>You're right. While the update algoritm should be fast, the API should
imply that work is involved and the caller should be smart about batching
these changes to avoid resource change events after each keystroke. I
think there's also a need for an API method for describing multiple
changes... I need to think some more about how this API would look.</JA>
------------------------------------------
* When a character range is deleted are the markers inside it
removed or moved/adjusted. Seem quite odd that they would move.
<JA>That might depend on what kind of marker ;) If a line of java code is
deleted, it might be appropriate to move a breakpoint to the nearest java
statement.
------------------------------------------
* Is the spec proposing the editor would have to make two calls, one
to adjust character positions and then another to adjust line positoinms.
<JA>As it is, the draft spec leaves line positions as an open question.
I'd like feedback from the editor folk on how these attributes are
currently used and updated.</JA>
------------------------------------------
* The spec indicates updating has to be blazingly fast, yet at the
same time it opens the door for anything to be done in an updater. This is
on top of what computation the editor may do.
<JA>The marker update should be as fast as possible, but the caller of the
update shouldn't rely on this. Calling the update on every keystroke
probably isn't appropriate... the editor needs to be (and currently is)
smart about when the update is called.</JA>
------------------------------------------
* (related to the above) Since updaters could be implicitly called
from any situation trying to update markers this makes me nervous. I would
rather see the person (i.e. editor) that is doing the updating actually be
fully in control/responsible for the fast marker update. This divides the
work where part of the work it does not necessarily control. [again keep
in mind the updater and editor are not necessarily the same plugin]
<JA>See the updated Motivation section in the RFC</JA>
