Re: [platform-core-dev] Re: New marker update API

["Greg Adams/OTT/OTI" <Greg_Adams@xxxxxxx>]

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

(Jeff: I don't know if I am argueing with you... but here goes).

*        Jeff's problem of premature activation (of the plugin) is a concern.
------------------------------------------
*        (related to the above) it may mean as soon as the user starts typing in the editor they get a displeasing pause while one or more other plugins get started.
------------------------------------------
*        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).
------------------------------------------
*        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).  
------------------------------------------
*        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.
------------------------------------------
*        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.
------------------------------------------
*        When a character range is deleted are the markers inside it removed or moved/adjusted. Seem quite odd that they would move.
------------------------------------------
*        Is the spec proposing the editor would have to make two calls, one to adjust character positions and then another to adjust line positoinms.
------------------------------------------
*        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. 
------------------------------------------
*        (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]
------------------------------------------
*        I disagree with Jeff's meta note - In my view markers are what users perceive them to be.  If we see opportunities for improving them to provide better user functionality then we should. Convincing all the clients its just a hash table and to live with it is not a useful activity and will probably just frustrate our clients. While I am not sure I agree with this proposal, I would caution against this general view of "just live with it".. Jeff if I misunderstand I apologize, but since I'm a client I thought it important to point this out. I will agree that we should not add behavior/api as point solutions without thought - which is exactly what this design prpoosal approach gives us.
------------------------------------------
*        The implication from Jeff's reply is that irrespective of whether or not we have an updateMarkers that if an editor simply wants to update markers on keystrokes (or at quiet points) this would be bad because they get wrapped in operations. This seems problematic to me.  It should be possible for editors to light-weight update editors (especially if the claim is they are just hash tables<g>).