add vscode go next command

[jmegner]

editor.action.nextSelectionMatchFindAction will jump to next hit of the current selection/token. I think if there is no selection and the cursor is not touching a token, then it will try to use the latest Ctrl+F search term.

[auscompgeek]

Should we replace the find_next implementation instead?

[nriley]

I tend to think of "go…" commands as navigation (changes your view/insertion point location) rather than search (affects the selection) commands. Most of the search commands in knausj are of the form "hunt…" — so for example "hunt this; hunt next" would do something similar to this. Cursorless also has "scout" that takes the usual targets.

There's a few different variations among the "start a text search in this file" commands:

• Does the selected text overwrite the search string?
• Does keyboard focus end up in the "search for" text field?
• Does the search execute?

The command as implemented here appears to be "yes, no, yes".

The standard VSCode Find command is "yes, yes, no" (though in most apps it is "no, yes, no").

VSCode and most Mac apps also have Find with Selection/Use Selection for Find (actions.findWithSelection) which is "yes, no, no".

Find next is "no, no, yes".

I think there's room for at least one more of these variants implemented in find_and_replace.talon and as an extended/additional user.find* action. I'm much less excited about creating a search command that only works in one app.

For example, we could make the text optional in "select next": https://github.com/knausj85/knausj_talon/blob/c8181e2876cd05cc9dfa4bfa7aaed209819088ce/tags/find_and_replace/find_and_replace.talon#L91

[AndreasArvidsson]

Should we replace the find_next implementation instead?

Exactly we already have a file with find commands and each application should context specifically implement these instead of adding new ones.
The existing one uses editor.action.nextMatchFindAction. I have no idea how editor.action.nextSelectionMatchFindAction differentiates.

community/apps/vscode/vscode.py

Lines 291 to 292 in 1413599

	def find_next():
	actions.user.vscode("editor.action.nextMatchFindAction")

[jmegner]

The existing one uses editor.action.nextMatchFindAction. I have no idea how editor.action.nextSelectionMatchFindAction differentiates.

editor.action.nextSelectionMatchFindAction goes to the next instance of whatever is selected/token-at-the-cursor; editor.action.nextMatchFindAction cares about what is in the Ctrl+F search text field and mostly ignores what is selected (I think the exception is if your search text field is empty, then it uses your selection for searching).

From a workflow/convenience perspective, it's nice that once something is selected, you can simply "go next" to go to the next instance of it rather than depending on the state of the search text field and worrying about whether the editor or the search thingy has focus.

I've also edited my initial comment to be more accurate:

editor.action.nextSelectionMatchFindAction will jump to next hit of the current selection/token. I think if there is no selection and the cursor is not touching a token, then it will try to use the latest Ctrl+F search term.

[AndreasArvidsson]

Okay that is a subtle distinction since most of the time when you are searching your selection is the same as the search result, but from your description I think we're use in the wrong thing. edit.find_next should go to the next search result regardless of your selection.
I would just update edit.find_previous and edit.find_next with the correct action identifiers.

[jmegner]

edit.find_next should go to the next search result regardless of your selection. I would just update edit.find_previous and edit.find_next with the correct action identifiers.

I agree. We have "hunt next" and "hunt previous" to call find_next and find_previous. I was proposing "go next" (and I should have had "go previous" too) as additions, but maybe it would make sense to have a command that makes it more obvious that it cares about selection/cursor-placement. Perhaps "go next/previous selection" like we already have "go next/previous mark"? I did it as a "go ..." command because that seemed to be the convention for many code navigation commands.

[AndreasArvidsson]

I don't think the commands that care about selection is intentional. I would argue we should just use the ones that goes to next search result. Or do you actually use both?

[jmegner]

I use both. Here is the appeal of "go next":

• I select/place-my-cursor-at a token I want to go to the next instance of.
• I say "go next".
• The next instance is selected with the cursor at the end. Nice, done.

Versus the "hunt ..." commands:

• I select/place-my-cursor-at a token I want to go to the next instance of.
• I say "hunt this".
• The search text field now has focus instead of the editor and vscode did not go to the next instance. Seems like the selected token is now the current search result, so I need to progress.
• I say "hunt next".
• Where is my cursor? Oh, it is still in the search text field.
• How do I move focus from the search text field to the editor?
• I guess I could send an escape key, but that would dismiss the search window, which I would like to keep so I can see what the current search term is.
• I settle and say "escape".

[nriley]

We discussed this on the community backlog session today and would prefer this be implemented as a variant of "select next" (see my prior comment: #1208 (comment)).