Switch targets to object-oriented

[pokey]

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)

[AndreasArvidsson]

• Remove inside/outside as proper modifiers
• Add start of/end of as proper modifiers
• Create a draft target type used in the pipeline. Gets converted into a function only finalized target at the end.
  • contentRange
  • deletionRange?
  • deletionDecorationRange?
  • leadingDelimiterRange?
  • trailingDelimiterRange?

[pokey]

I think we prob potentially want edit constructors instead of ranges, eg for camel-case, no?

[pokey]

I think we prob potentially want edit constructors instead of ranges, eg for camel-case, no?

[pokey]

I think we prob want constructInsertionEdit to take a list of texts, so that we can handle #184

[AndreasArvidsson]

We can do that