Proposal: Selecting ranges inside atomic Textmarkers


#1

The current implementation does not allow a call to cm.addSelection() to pass in a range that falls within an atomic TM (and documentation makes this wonderfully clear). Note that I’m not saying the current behavior is wrong – just proposing a change.

It’s clear that the cursor can’t fall within an atomic range (without violating the semantics of atomic), and certainly, if I can’t put my cursor inside an atomic range, I could never manually select a range contained with it it. But it’s less clear why a programmatically-defined selection couldn’t fall within that range.

This change wouldn’t impact cursor movement, or non-API selection. I also can’t think of a use-case in which an API-selected region relies on this being forbidden. This would be enormously useful for a project I’m contributing to, which will allow any CM instance to turn into a block-based editor if a (traditional) parser for the language is available. Since we’re replacing code with DOM trees, we’d like to allow copy/paste on subtrees, which fall within a the range of the TextMarker.

I’m sure there are angles I’m missing, but if this change is doable it would allow us to use CM’s wonderful selection API instead of rolling our own.


Adding custom information to history object
#2

There is no difference between user selection and programmatic selection, since user selection is just programmatic selection triggered by a command bound to a key.

The very definition is atomic ranges is that you can’t partially select them. I am not really interested in making them mean something else.