Support for each line in the editor to have unique id that would be retained in memory for the duration of the session, and which could be re-loaded later for new sessions.
Persistent line ids can be used as a reference to later link to specific lines, or associate comments or line highlights.
notes:
When new line is created in the editor, it’s assigned a unique id and kept in memory. Probably a hash of sufficient entropy so as to minimize shadowing when a line is later removed (its id destroyed) and new line created elsewhere.
Or better yet, allow users to supply their own id generator.
The editor should try to retain line id across various modifications (either done via API or user interaction), such as when:
lines are swapped (e.g. via SublimeText keymap)
when you prepend/paste a newline at the start of line
when folding
when lines are moved e.g. via select + drag, or via cut + paste
Ability to export/import the line ids (e.g. as array of ids) so that they can be persisted to server, and later fetched and reloaded for new editor session.
I’m thinking one could add this to CM5, but IMO better if the editor can do this natively or allows easy bake-in via plugin, hence CM6 (if this makes sense to you guys).
This is unlikely to be come part of the editor core. Our document model is that of a plain sequence of line strings, and that’s working well. You can implement ID tracking in a plugin, but making it work for things like moving lines around wouldn’t be easy (since, again, the clipboard works with plain text, not tagged objects, and the same goes for default editing commands).
but making it work for things like moving lines around wouldn’t be easy (since, again, the clipboard works with plain text, not tagged objects, and the same goes for default editing commands).
Yes, there will have to be some state management that will take care of this. If CM6 will expose API to get the line objects as current CM does, and won’t trash the objects willy nilly, then an implem via plugin shouldn’t be crazy hard.
There won’t be line objects any more, so that approach isn’t likely to work (also, when moving lines around in version 5, the line objects will be lost, so they don’t buy you much).
Mhm… that would leave us with string comparisons which could in theory work for 95% use cases. I wonder, how are you gonna keep track of markers, folds, widgets, gutter bookmarks etc. if all you have is strings all the way down?