We require contributors to sign our Contributor License Agreement, and we don't have @tomoikey on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

The cla-bot has been summoned, and re-checked this pull request!

The cla-bot has been summoned, and re-checked this pull request!

@SomeoneToIgnore

I've added the remote support

Thank you for addressing the remote mode!!!
I fixed the issue where signature_help was not displayed when entering ( from the fooˇ state, even if auto_signature_help was enabled. I also added two new tests for this.

Movie

I've tested it and got somewhat confused

Regarding the combination of settings, I agree that some patterns might be confusing. However, we need to ensure that they do not interfere with each other. Using a mathematical set theory analogy, the intersection of the set auto_signature_help and the set show_signature_help_after_completion (A ^ B) should be an empty set. If the intersection of these two setting sets is not empty, it would lead to a loss of customization (independence) of the settings.

Therefore,

• When “auto_signature_help” is true, signature_help should be triggered by cursor movement or bracket input.
• When “auto_signature_help” is false, signature_help should not be triggered by cursor movement or bracket input.
• When “show_signature_help_after_completion” is true, signature_help should be triggered after completion.
• When “show_signature_help_after_completion” is false, signature_help should not be triggered after completion.

This way, the settings are independent and highly customizable without interfering with each other. If additional needs arise, these should be further divided independently or new independent settings should be added.

Additionally, I split the modules into several parts as various concepts were mixed within a single file.

One remote test had failed, surprisingly, I can investigate it on Thursday, welcome to fix it before if you get to the root of it.

This Thursday and Friday, it is highly likely that I will not be able to allocate time due to a company event.
If it’s a minor issue, I might be able to handle it, but I probably won’t have enough time, so @SomeoneToIgnore will likely discover any issues during the investigation on Thursday.
If the investigation proves challenging, I will try to find some spare time to help as well.

On a side note, interactions on GitHub feel very asynchronous and inconvenient for collaborative development.
If you don’t mind, I would appreciate it if we could use a chat application like Slack for communication. However, I understand the concerns about privacy, so it’s okay if you prefer to ignore this suggestion.

However, we need to ensure that they do not interfere with each other.

Why not?

My whole point is that by ensuring that they do not interfere, we make it less intuitive for certain languages.
For

"auto_signature_help": true,
"show_signature_help_after_completion": false,

issue, doing self.fˇ -> self.foo(ˇ) puts the caret between the brackets, and, as seen on the video, moving the caret around, keeping it between the brackets, does not invoke the popover while it should, according to auto_signature_help — there's no autocompletion happening after a few key presses.

This way, the settings are independent and highly customizable without interfering with each other. If additional needs arise, these should be further divided independently or new independent settings should be added.

What does this chatgpt-esque phrase mean? What is the point of the behavior, described above and who would want that?

I propose to rework the settings, if you find this configuration confusing.
My idea is to have a way to gradually enable the feature:

pub enum SignatureHelpPopovers {
    Off,
    AfterCompletionsOnly,
    Everywhere
}

there's a fourth variant, EverywhereExceptAfterCompletions that I describe above and find redundant.

@SomeoneToIgnore
There has been a misunderstanding because what you think of as auto_signature_help and what I think of as auto_signature_help are different. I understood auto_signature_help to be something that triggers when crossing existing brackets, but you seem to mean something that triggers when surrounded by brackets. So, I had no issue with the signature_help not appearing after completion when auto_signature_help: true, show_signature_help_after_completion: false.

I have no choice but to imagine what behavior the Zed team wants for Zed from your words. It is natural for ambiguity to arise when using natural language. I am not good at English. The reason I sound like ChatGPT is that I am using ChatGPT as an intermediary for communication with you. I understand that I am taking up your time due to communication issues. I apologize for that.

After dinner, I plan to create a combined setting for auto_signature_help and show_signature_help_after_completion, as you suggested. However, the settings in the top right corner of the screen are toggles, so it seems they can’t represent more than three values. How would you like to handle this?

pub enum SignatureHelpPopovers {
    Off,
    AfterCompletionsOnly,
    Everywhere
}

something that triggers when crossing existing brackets

But isn't self.f -> self.foo(ˇ) also a "crossing", given that mouse-clicking into the middle of baz(foo, ˇbar) works already, hence also considered as "crossing"?
Generally, I am not sure that crossing is a good verb/approach, and was thinking in surround terms all this time.

I have the following ideas on the settings:

• we should have a mode to always show these parameters because certain people liked that

"auto_signature_help": true,
"show_signature_help_after_completion": WHATEVER,

• we should have a way to never show these paremeters because people prefer minimalism

"auto_signature_help": false,
"show_signature_help_after_completion": false,

• we should have a middle ground enabled by default, so that the feature is notable by people

"auto_signature_help": false,
"show_signature_help_after_completion": true,

The middle ground was chosen to be "after the completions only" as something very useful feature-wise.

2 existing parameters are just fine with that logic if and SignatureHelpPopovers enum could stay as a mental model, as it feels simpler this way.
Then, the toggle is fine to change the auto_signature_help only.

But if you want to use the enum, I'd keep the toggle switching between SignatureHelpPopovers::Everywhere and either what was in settings (if it was not SignatureHelpPopovers:Everywhere, by default that would be SignatureHelpPopovers::AfterCompletionsOnly) or SignatureHelpPopovers::Off otherwise.

ChatGPT

Regarding the combination of settings, I agree that some patterns might be confusing. However, we need to ensure that they do not interfere with each other. Using a mathematical set theory analogy, the intersection of the set auto_signature_help and the set show_signature_help_after_completion (A ^ B) should be an empty set. If the intersection of these two setting sets is not empty, it would lead to a loss of customization (independence) of the settings.

I understand that you have to use your ways for translations which is fine per se, and my remark was not targeted at that part.

My main problem with that phrase is how "water is wet, sun rises on the east" those words are, not moving us towards an actionable resolution of the issue, something like I've tried to do in the previous comment.

The point is to identify the point of confusion, make it well usable for people and implement it without bugs, while such generic phrases bring nothing but extra confusion and the discussion bloat.

That's why I'm not sure that using a less async way of communicating will help here — from my perspective, all I constantly do in this PR for a month is: coming, opening the very same pet project, clicking around a few minutes and seeing more issues, sometimes in the very same sequence of actions.
Even the new test code appeared so far only when I noticed that this is a logic issue and has to be tested.
The velocity gets crippled not by the lack of sync approach, but rather an absence of initiative(?) and absence of testing the work on some approximation of the real projects. Maybe, it's not very clear how the feature should look like?

I want to emphasize that I do not aim to attack or anyhow express hostility with such messages, but rather provide some feedback and attempt to highlight the issues.
I'm fine with finishing this PR and the way it moves on too, but would fine as well to trade some velocity in favor of a better discussion quality.

@SomeoneToIgnore
Thank you for your suggestions.
When you say "WHATEVER" in

"auto_signature_help": true,
"show_signature_help_after_completion": WHATEVER,

do you mean "true", or do you want to introduce a new concept of "WHATEVER" in addition to "true" and "false"?

This should really be enabled by default

Anecdotally, it took me a long time to find this feature because I was looking for "parameter hints" or "argument hints" and didn't think to search "signature"

This should really be enabled by default

+1. I ended up here while trying to figure out why this feature wasn't enabled when I typed (.

This change actually does enable the feature by default (note show_signature_help_after_edits is true). However, it seems this flag was disabled in #20726 to mitigate issue #20725.

I agree that we should enable it by default (this is also the standard behavior in VS Code). If users don't need the popup, they can simply press esc. @SomeoneToIgnore