Skip to content

Conversation

@ghentschke
Copy link
Contributor

fixes #1339

@ghentschke
Copy link
Contributor Author

grafik

@mickaelistria
Copy link
Contributor

JDT has "trigger chars" which allow users to configure more than 1 character in a freetext field. Could we mimic it for this use case?

@mickaelistria
Copy link
Contributor

I wonder whether those "excluded" strings should instead be configured by language server. For example, what about } ? Or, if we're doing Pascal or Ada, those should exclude end; if doing bash, it should exclude fi ?

@ghentschke
Copy link
Contributor Author

JDT has "trigger chars" which allow users to configure more than 1 character in a freetext field. Could we mimic it for this use case?

Sure. I can replace the check box with a free text field to allow users to specify other, language specific, characters.

I wonder whether those "excluded" strings should instead be configured by language server. For example, what about } ? Or, if we're doing Pascal or Ada, those should exclude end; if doing bash, it should exclude fi ?

I think this is a little complicated. It was my first idea as well and I posted a clangd issue. But this response pushed it back to the editor side. In C++ it is allowed to write a new statement after ; without any space. So the LS works correctly when returning a proposal after a ;. But for many users its at least annoying to get a proposal pop-up when they just want to enter a new line. The proposal is not shown in VS code.

@ghentschke
Copy link
Contributor Author

A text box would invert the logic: Do not trigger on: It would act like a filter.

@mickaelistria
Copy link
Contributor

I'm genuinely wondering how users would like (or not) get get ; replaced by eg ;\t\t\n when tying it as last char of a line... Maybe that would actually please user to have such auto-edit in the LS and it would resolve the story decently.

@ghentschke
Copy link
Contributor Author

ghentschke commented Oct 15, 2025

That's exactly what the on-type-formatting does. But that's a different story.

@mickaelistria
Copy link
Contributor

That's exactly what the on-type-formatting does. But that's a different story.

I think it's the same story, but not on the same stage.
If clangd autoformatting is already doing that, then how can user get to the case where they're annoyed by completion just after ; since "just after ;" should be about never with ontype formatting?

@ghentschke
Copy link
Contributor Author

ghentschke commented Oct 15, 2025

Please take look of the original cdt-lsp issue eclipse-cdt/cdt-lsp#550. There is a GIF that explains the problem during typing.

The on-type-formatting kicks in after the new line has been applied. But there is no new line applied after pressing the enter key. Instead, the proposal i being applied which is not wanted at that point.

@rubenporras
Copy link
Contributor

On a different track, In eclipse-cdt/cdt-lsp#550 you mention than VS built a workaround. Since the code is open source, did you checked what that workaround could be? Maybe we could use that as inspiration.

@mickaelistria
Copy link
Contributor

The on-type-formatting kicks in after the new line has been applied.

The onTypeFormatting notification could probably kick it anytime. Could the Language Server trigger it on pressing ; to automatically add a new line and indentation?

@ghentschke
Copy link
Contributor Author

ghentschke commented Oct 15, 2025

The LSP is a bit vague in the definition of the onTypeFormatting. See this comment.

The current LSP4E implementation of onTypeFormatting checks the document changes. If there is a trigger character found (clangd triggers on \n only) the onTypeFormatting request is sent to the server. This has to be done after the \n has been written/applied to the document. This has the advantage that other Eclipse based on-type-modifications like indention from TM4E are known to the LS and can be considered when calculating the TextEdits.

Why should a onTypeFormatting being triggered/send when the user types ; ?

The problem here is, that the proposal get triggered/opened by ;. When the user presses then the enter key, the proposal will be inserted. That's not wanted.

Instead of:

i = i + i;

we get (b is on top of the proposals) when pressing enter:

i = i + i;b

@mickaelistria
Copy link
Contributor

My main concern is that hardcoding ';' is a language-sepecific feature, so would be hardocding { or }, or End With...
So I'm a bit reluctant to allow a general-LSP4E level configuration for something that is deeply language-specific. Would there be some possible info from the language server, or even textmate or language-configuration.json that would allow the string/chars that are usually last on line?

That's why I'm wondering whether it would be interesting to get the LS (clangd here) enable onTypeFormatting for end line (eg ; or {) directly, and tweak the insert so that those chars would immediately add a new line and shift caret.
I will give it a try with some dummy LS to get an idea of whether this looks good in term or usability (in which case we can try to push to to clangd, jdt-ls and so on) , or not (in which case we can discard this idea)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Do not invoke completion proposal on statement terminator

3 participants