Can we count on text marking objects to stay persistent as the editor is being used? Can we, in particular, add payloads to those objects and expect to get them back when invoking marking-retrieval methods?
It sounds risky to put payloads directly on the marking object without some standardized property to house the payload; we may inadvertently overwrite undocumented internal properties. Can we standardize a way to put payloads in markings?
At a minimum, assuming we are allowed to use such payloads, can we document the persistence of the text markings to solidify this feature?
Oh, ignore my other reply, I was context-switching and still thinking about another project. Yes, in CodeMirror, the extra data you put onto mark objects stays around.
Indeed, but clients need to come up with a property to put the extra data in, and that property may already be used by TextMarking internally. If I use the property “id” and I upgrade CodeMirror to a version that starts using “id” for its own purposes, what then?
Can we come up with a dedicated property for this and have it documented as a contract?
I’ve been using properties starting with underscores for this. If you want to submit a documentation PR that documents a specific property/option for this purpose, I’ll gladly merge it.