UX and other improvement thoughts (that I'm happy to help contribute)

[SCWells72]

Starting this discussion here instead of opening a series of issue tracker items to see whether the latter makes sense. As I've been integrating LSP4IJ (loosely) into my own plugin (see this), I've been noting things quirks and opportunities for improvement where I might be able to help. I've just opened my first PR against the project for one of the simpler ones -- and no issues if it's not accepted in its current form -- but here are a few other things that I've noted on my list:

Config UX improvements

• When table rows are added to the Mappings tables, automatically focus/start editing on the first cell as it's not completely obvious that a new row has been added at present. This is obviously very low-hanging fruit and simple to implement.
• Change the Configuration text fields to be EditorTextField components pre-configured for JSON, e.g. (from some similar fields in my own plugin):
  
• Figure out and fix whatever is going on with the inconsistent behavior of code completion tail text where, at least in TypeScript, it (sometimes?) doesn't show initially but does when you cursor up/down in the completion list.
• Try to improve/fix support for TypeScript completions.completeFunctionCalls configuration:

  This functionality relies on LSP client resolving the completion using the completionItem/resolve call. If the client can't do that before inserting the completion then it's not safe to enable it as it will result in some completions having a snippet type without actually being snippets, which can then cause problems when inserting them.

Just wondering if a) there are already folks here working on these; or b) whether there would be any objections if I were to dig in on them and contribute them back via a series of PRs. Thoughts?

[angelozerr]

Starting this discussion here instead of opening a series of issue tracker items to see whether the latter makes sense. As I've been integrating LSP4IJ (loosely) into my own plugin (see this), I've been noting things quirks and opportunities for improvement where I might be able to help. I've just opened my first PR against the project for one of the simpler ones -- and no issues if it's not accepted in its current form -- but here are a few other things that I've noted on my list:

Config UX improvements

• When table rows are added to the Mappings tables, automatically focus/start editing on the first cell as it's not completely obvious that a new row has been added at present. This is obviously very low-hanging fruit and simple to implement.

This UI was not our priority. We wanted to have a good UI to declare server mappings etc but I agree it should be improved. Any contribution are welcome!

• Change the Configuration text fields to be EditorTextField components pre-configured for JSON, e.g. (from some similar fields in my own plugin):
  

Indeed it would be nice. I have never seen a language server which uses an anotjer language than json for configuration. Any contribution are welcome.

• Figure out and fix whatever is going on with the inconsistent behavior of code completion tail text where, at least in TypeScript, it (sometimes?) doesn't show initially but does when you cursor up/down in the completion list.

Sorry I dont understand the problem. Please create an issue with some screenshot, detailled info.

• Try to improve/fix support for TypeScript completions.completeFunctionCalls configuration:

  This functionality relies on LSP client resolving the completion using the completionItem/resolve call. If the client can't do that before inserting the completion then it's not safe to enable it as it will result in some completions having a snippet type without actually being snippets, which can then cause problems when inserting them.

Just wondering if a) there are already folks here working on these;

No

or b) whether there would be any objections if I were to dig in on them and contribute them back via a series of PRs.

Any contribution are welcome!
Thoughts?

[SCWells72]

Sorry I dont understand the problem. Please create an issue with some screenshot, detailled info.

Let me know if this doesn't help:

[angelozerr]

Thanks for the demo. This behavior is because typescript language server manages details on resolve completion to speed performance.

[SCWells72]

Okay, so it's the same issue that's preventing completions.completeFunctionCalls from working properly. I suspected that might be the case. Thanks for the clarification.

[angelozerr]

@SCWells72 the best thing to contribute is that you create an issue per features.

We uses label to mark issues and it seems you want to work on

• LSP console UI, see issues https://github.com/redhat-developer/lsp4ij/issues?q=is%3Aissue%20state%3Aopen%20label%3Alsp-console
• User defined language server, see issues https://github.com/redhat-developer/lsp4ij/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22user-defined%20LS%22

Change the Configuration text fields to be EditorTextField components pre-configured for JSON, e.g. (from some similar fields in my own plugin):

For this topic, I think to improve this JSON configuration we should provide:

• JSON syntax coloration
• JSON validation
• Associate configuration with a JSON Schema tio have completion, validation based on a Schema which describes the expected settings (we could use package.json for some language servers whichdeclare that for vscode and a custom JSON Schema for typescript for instance which have no vsocde integration with typescript-language-server since vscode uses directly tsserver).

Writing configuration from a textarea is a little annoying, I think we should provide the capability to edit the JSON from a real editor.

There are a lot of work to do about this topic, but it is not our priority for IJ Quarkus which doesn't use user defined language server, so I cannot work on it, but I will be happy to review any PRs.

[SCWells72]

JSON syntax highlighting is pretty simple. JSON syntax validation is also quite simple if you have a JSON schema and your running in a commercial JetBrains IDE; the free Community Edition IDEs don't include JSON schema validation or schema-based code completion. You would need to use an external validator in those IDEs. In my plugin, I decided to use what the respective IDE offers only and it seems to have provided sufficient improvements even in Community Edition. Just syntax highlighting, auto-indentation, and brace matching is a big step up from a raw text fields.

[angelozerr]

I'm using IJ Community 2024.2 and I have JSON support (syntax validation and JSON Schema based). But perhaps IJ have changed that with the last version of IJ community?

I think we should not reinvent the wheel to manage all JSON support (validtaion, auto-indentation, etc). I think we should provide an
Edit in an editor link after Configuration label which will open the content of the Configuration textarea in an classic editor and we will benefit out of the box from JSON support, OR perhaps if we change the basic textarea with an EditorImpl by setting with the JSON language we could perhaps having JSON support. If this solution is working that's nice but we need to manag etoo the usecase when the JSON plugin from Jetbrains is not available (ex : running LSP4IJ inside CLion).

IJ community provides too a JSON Shcema provider (that we use in our IJ Quarkus) and we could implement it for LSP4IJ user defined language server to benefit with completion, validation etc according the expected JSON configuration of the language server.

[SCWells72]

Apologies but I misstated a bit. What I meant is that the JavaScript.JsonSchema.ProviderFactory EP is only available in commercial edition IDEs. Yes, you're correct that you can register and use a JSON schema file in Community Edition IDEs; you just can't register one that's bundled within your plugin dynamically for a file. I'm not sure what that would mean for trying to apply JSON schema validation using the IDE's facilities to an ad hoc EditorTextField in Community Edition, but I'm happy to take a look at some point shortly. Note that this is a holiday week for us and our kids are out of school, so I don't know how much time I'll get to look at it this week, but I'll try to dig in very soon.

[angelozerr]

You need to work with VirtualFile (see https://github.com/redhat-developer/intellij-quarkus/blob/main/src/main/java/com/redhat/devtools/intellij/quarkus/json/QuarkusJsonSchemaProvider.java)

I will try to implement VirtualFile or using for instance FakeVirtualFile

[SCWells72]

So interestingly while you (or at least I) would assume that the JavaScript.JsonSchema.ProviderFactory EP is only available when, you know, the JavaScript plugin is available, it's actually part of the JSON plugin which is always available. Turns out that dynamic JSON schema support works in all editions, so validation will be pretty simple to implement...once I locate the JSON schema for these configs.

UPDATE: Maybe...I'm seeing it work in Community Edition in a debug instance, but I need to confirm that it will in reality... More info to come shortly.

[fbricon]

Change the Configuration text fields to be EditorTextField components pre-configured for JSON, e.g. (from some similar fields in my own plugin)

@SCWells72 feel free to take #157 over

[angelozerr]

@SCWells72 I close the issue since you have done so many contributions.