Parameter hints do not get dismissed when the cursor moves

[aaronjensen]

Presently, it appears that the parameter hint window does not get dismissed if it is brought up when invoking a function within the argument list of another function and you move out of the inner function's argument list. The popup changes to reflect its new position, but this is not a generally useful thing and in something like a giant argument list like a call to webpackMerge this is incredibly irritating. Couple this with the fact that the Vim extension does not dismiss the param hints when you press escape and it's pretty rough.

It would be really nice if the parameter hints were dismissed when leaving the current argument list. I can see an argument for it remaining open while navigating around the current argument list, but if the cursor leaves that list and goes to an outer list, it should be dismissed.

Thanks!

• VSCode Version: 1.27.0 - insiders and 1.26.0
• OS Version: macOS 10.13.6

Steps to Reproduce:

1. Open a new file

2. Change to javascript mode

3. Enter the text:

   const path = require('path')
   
   Array.isArray([
     baz,
   
   ])

4. Place cursor on line after baz

5. Type Array.apply(. The parameter hint overlay should appear.

6. Press the up arrow.

Expected:
Parameter hint window is dismissed

Actual:
Parameter hint window remains covering code

Does this issue occur when all extensions are disabled?: Yes

[mjbvz]

@DanielRosenwasser VS Code sends two signatureHelp requests to the TS Server here:

• First the trigger ( after typing Array.apply(. This has

  "triggerReason": {
      "kind": "characterTyped",
      "triggerCharacter": "("
  }
  

• Then the cursor move up one line:

  "triggerReason": {
      "kind": "retrigger"
  }
  

In the second case (retrigger without any typing) we may want to stop returning results if the signature changes.

On The VS Code side, we just added an activeSignature field to the signature trigger context that could allow an extension to do this: microsoft/vscode#33413

• Do you think dismissing signature help for cases like this makes sense
• Could TS use something like an activeSignature to do this? Or perhaps provide a signature identifier that would let VS Code implement this?

[DanielRosenwasser]

The motivation of a retrigger is to say "hey TypeScript, signature help is already being displayed - you should try to keep it around and see if there's still a signature around." So either the editor needs to know "no, we shouldn't send a re-trigger" or the language service has to come up with some rules to say "no, even in the presence of a retrigger, this would be so bad that we shouldn't return any results."

So I guess the question is, what exactly makes this case different from a couple of nested calls? I can see this isn't the most ideal experience, but I can't formulate that into something general for the language service or editor.

[aaronjensen]

what exactly makes this case different from a couple of nested calls?

Could you clarify what you mean here? This does happen with a couple of nested calls.

My expectation is that moving the cursor would remove the tooltip. Perhaps it could just be a movement that changes the current line that would not retrigger. I can see a reason for wanting to keep the tooltip up while working on a single line (hit left arrow and still want to see the docs to reorder params, for example).

[DanielRosenwasser]

Could you clarify what you mean here? This does happen with a couple of nested calls.

Sure - I meant that because we do this in any other nested call, it's not clear why this should be different. What I was wondering is if there's a special case of this where we could avoid the issue entirely.

My expectation is that moving the cursor would remove the tooltip

I think that's reasonable, but others will have the opposite issue. I don't think we'd ever change the behavior entirely unless it was behind a switch.

[aaronjensen]

I'm good w/ a switch. As it is, I've disabled them completely. It's exacerbated by the fact that they're not cleared when hitting escape w/ vsvim.

[DanielRosenwasser]

It's exacerbated by the fact that they're not cleared when hitting escape w/ vsvim.

That does sound painful! Not sure how else you can dismiss it without reaching for the mouse, so that may be a separate thing that VS Code may want to check into.

[mjbvz]

@DanielRosenwasser For nested calls, should moving the cursor between calls continue to show signature help? I think it makes sense to continue showing it if the user types ) to close the inner function call, but am not sure about just moving the cursor to the outer function call when it was triggered for the inner call.

[DanielRosenwasser]

I think it's been super helpful personally. It's also the way that C# works IIRC, so there's precedent.

[DanielRosenwasser]

Also, how is the LS supposed to differentiate between whether a retrigger occurred in the same call as before? If you just eliminated cursor moves entirely, signature help would be killed off as soon as you make a typo and have to move your cursor back once.

[mjbvz]

That's where microsoft/vscode#33413 comes in. Or if TS added a call_id property to signature help items, VS could could use that id to track when the call changes

[mjbvz]

Another example without nested calls:

console.error(1, )
console.log(   1|  )

1. With the cursor at the |, type , to show parameter hints.
2. Move cursor up a line. Signature help is still shown but now for console.error instead

I feel that dismissing the signature help would be the expected behavior here