`@scope.prefixRange` target attribute

[pokey]

The problem

Consider the "access" scope (eg .aaa). Should the . be in the leading delimiter range or the content range? If the . is considered part of the content range, as it is today, then "bring access air" when sitting after bbb would work well, but "change access air" would not, as you likely want that . to stay there. On the other hand, if we include . in the leading delimiter range, then "change access air" would work well but "bring access air" when sitting after bbb would not.

The solution

Introduce a new @someScopeName.prefixRange target attribute.

Example scopes that could benefit:

• Comments (the # would be the prefix)
• @foo in .scm files (the @ would be the prefix)
• items in markdown / yaml (the - would be the prefix, including all spaces until first nonwhitespace char of content)
• "access" (the . or ?. or -> would be the prefix)

Relevant actions (using S as the relevant scope):

• "change S" => exclude prefix
• "copy S" => include prefix
• "bring S" with cursor is on an empty line / not after a delimiter => include prefix
• "bring S" where cursor is sitting just after the delimiter of an empty S (eg "bring access air" and your cursor is after foo.) => exclude prefix. Might be extra credit to support this one but would be cool
• "bring S" with a full S selected => include prefix
• "bring S" with content range of an S selected => exclude prefix
• "bring S1 to S2" => either both S1 and S2 exclude or both include prefix
• "bring T to S" (where T is not an S) => exclude prefix
• "bring S to T" (where T is not an S) => include prefix
• "chuck S" => include prefix
• "clone S" / "clone up S" => include prefix
• "drink S" / "pour S" => include prefix

Using today's abstractions, we could either include the prefix in the leading delimiter or the content range. If we draw a matrix of actions with scopes above, then either decision results in suboptimal behaviour. For example, if we include prefix in content range, then "bring S" on an empty line would work well, but "change S" would not. And vice versa: if we include prefix in leading delimiter range, then "change S" would work well but "bring S" on an empty line would not.

If we have the prefix be its own range, then we can make sure all the above use cases work well. Note that it exists in addition to the leading range. Ie for a markdown item, the - is the prefix, and the leading newline past the indentation should be the leading range.

Examples that might be prefix, but we're not sure

• function decorators in Python?
• jsdocs?

See also

• Support destination pseudo-scopes #1631
• Add "access" scope type #1519
• Include @ in name for scm language #1927
• Change name scope in scm language to include the @ #1923
• Migrate collection item and argument scopes #2081