cursorless
cursorless copied to clipboard
Automatically detect delimiter for scope type targets
I tried "pour element", and found it quite bothersome that it tried to insert a space instead of making a new line, like the old behaviour. I would argue that we should detect if something stops at a line boundary and use newline delimiter if so.
@AndreasArvidsson I believe you had some reason why we shouldn't do that but I can't remember what it was
Do you want this behavior only for pour or also for bring? Should some scopes types be omitted? Because now when we have textual item scope "pour item"
should definitely not insert a line just because it is the last token on the line.
If something is the last token on the line it will not count as a line. It needs to start and end on line boundary
It will also only be if the scope type has no explicit delimiter set, so wouldn't affect item for that reason as well
I guess for scope types that have no specific insertion delimiter this could work. How will you handle multiline targets? Check both first and last line? Leading and trailing white space will be omitted from the line calculation?
Yep!
I think we can also consider detecting we're a block and set it to \n\n
, though not quite as critical as the newline one. That one gets me because it feels like a regression in situations like this one
This one is also super annoying for "section" in markdown, eg "clone up section"
The current solution for these is of course that they have the wrong delimiter. Section should definitely not insert or remove as a token.
Yeah maybe for now let's just add them to that switch statement, but I do worry it's going to start feeling like a game of whack-a-mole
Agreed. We should definitely have a proper look at an alternative solution. But just for now I think we should just add them to the delimiter list.