Execute find command twice will choose the first selected item

[xzbdmw]

Sometimes I trigger the search command in terminal and want to search it later, then I hide the terminal, and second time I trigger the command it will make me jump to the first selected item from the hidden terminal, maybe type command twice without enter can just open panel(if it is invisible) and does nothing?

[tomrijndorp]

Hi @xzbdmw, thanks for reporting. I'm aware of this. Unfortunately because VS Code doesn't give much control over the terminal, it's a pesky one. I'm not sure if it can be solved.

[darianmorat]

Hi @xzbdmw, thanks for reporting. I'm aware of this. Unfortunately because VS Code doesn't give much control over the terminal, it's a pesky one. I'm not sure if it can be solved.

If you close the terminal and open it again using toggle panel visibility is gonna be left in the search that was made before. That's the request right? You could maybe add an If statement that tells if the cx has used the command without enter and if the command is trigger again is gonna send toogle panel visibility instead of the command

[MangelMaxime]

I investigated a bit and it seems like the flow is the following:

1. Request "Fint It Faster: search file"
2. A terminal is open and all is good
3. Request "Fint It Faster: search file" (without having selecting a file in step 2)
4. Then the extension is sending `/find_files.sh '/Users/mmangel/Workspaces/Github/ionide/ionide-fsgrammar/sample-code' + a CR
5. This new text tells fzf that the user selected <path_to_extensions>/find_files.sh '/Users/mmangel/Workspaces/Github/ionide/ionide-fsgrammar/sample-code' but because the file doesn't exist then fzf returns 1 meaning- 1: No match`

Source - FZF CHANGELOG

0.10.6
------

- Replaced `--header-file` with `--header` option
- `--header` and `--header-lines` can be used together
- Changed exit status
    - 0: Okay
    - 1: No match
    - 2: Error
    - 130: Interrupted
- 64-bit linux binary is statically-linked with ncurses to avoid
  compatibility issues.

This behaviour can be confirmed by telling VSCode to not execute the command provided term.sendText(getCommandString(commands[cmd]), false);

https://github.com/tomrijndorp/vscode-finditfaster/assets/4760796/0aa1c068-3507-4225-966c-b366f54b0163

Using VSCode API it is possible to send Ctrl+C to a terminal:

await vscode.commands.executeCommand("workbench.action.terminal.sendSequence", { text : "\x03" });

I am trying to explore if we send Ctrl+C every time before running find_file.sh as it would allows us to detect that fzf was just interrupted and ignore that result.

And then we could load a new instance of find_file.sh reverting in a more usable state. We will still lose any query that the user could have written in the previous fzf process but at least this would avoid avoid to call find_file a third time to return to a usable state.