Description
The problem
As we move towards fully compositional cursorless modifier pipelines (#69), each cursorless target needs to have enough information so that subsequent pipeline steps can do their job. In addition, we have found that oftentimes different actions need to repeat the the same code to operate on a given type of target. For example, the "chuck"
, "move"
and "carve"
commands all need to know how to remove a given target. We'd like to bake more intelligence into the targets themselves.
In addition, once we have #46, we want to have rich targets that can refer to more than just locations in a document. Having smart targets will enable many advanced use cases. See What's next for more.
The solution
Target will become object-oriented, with the following methods
getContentSelection
(used for selection, get text, highlight for reference)getRemovalDecorationRange
constructChangeEdit
(takes text)constructInsertionEdit
(takes text and returns edit that has range as a selection, so that paste can use empty string then set cursor to active before pasting)constructRemovalEdit
The target will also have the following, but somehow hide it before action sees it because it shouldn't be used there. It's mostly for downstream pipeline stages, eg "after":
- Trailing delimiter range
- Leading delimiter range
- Parent: can use this one (combined with "children" below) to automatically implement Support
"every <scope>"
/"<ordinal> <scope>"
#51 / Add support for “grand” scopes #124 - Children
Other stuff to think about
Positional modifier is just a pipeline stage
Need to have proper "insert" command and then can distinguish between "insert after" vs "change after" (changes delimiter)