Add preference option for non-buffered file handling in Xtext editors.

[raghucssit]

see #1500

[Copilot]

Pull request overview

Adds a UI preference to control “non-buffered file handling” so LSP4E can better support editors (e.g., Xtext) whose IDocument is not backed by Eclipse file buffers, aligning with #1500.

Changes:

• Added a new translatable UI label for the preference.
• Exposed a new checkbox on the Language Server preference page backed by org.eclipse.lsp4e.resourceFallback.enabled.
• Persisted the checkbox value to the plugin preference store on OK.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
org.eclipse.lsp4e/src/org/eclipse/lsp4e/ui/messages.properties	Adds the UI string for the new preference checkbox.
org.eclipse.lsp4e/src/org/eclipse/lsp4e/ui/Messages.java	Exposes the new message key to the NLS bundle.
org.eclipse.lsp4e/src/org/eclipse/lsp4e/ui/LanguageServerPreferencePage.java	Adds the checkbox and saves/loads the preference value.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rubenporras]

Hi @raghucssit ,

I think the end user should not be interested in such flag. Could we instead enable it in the Activator of CoPilot plugin?

[iloveeclipse]

I think the end user should not be interested in such flag. Could we instead enable it in the Activator of CoPilot plugin?

The point is, it is needed by Xtext & Copilot (as of today), but provided by LSP4E. If there will be some other plugin that needs same preference, should there be another preference page? Surely not. I don't see a big problem in providing an option in LSP4E for this feature, if there will be no complains with the new code, it can be removed later.

@raghucssit : can you please attach a screenshot of the preference page? I do not have time to load this patch into IDE, and code reading doesn't replace visual check.

Beside this, I miss one important thing in this PR: the new support should by enabled by default with this preference page, that is one of the main reasons to have the page at all - if the new support breaks something in LSP4E/clients of it, it should be possible to users to fix that without waiting for new release.

[raghucssit]

I think the end user should not be interested in such flag. Could we instead enable it in the Activator of CoPilot plugin?

The point is, it is needed by Xtext & Copilot (as of today), but provided by LSP4E. If there will be some other plugin that needs same preference, should there be another preference page? Surely not. I don't see a big problem in providing an option in LSP4E for this feature, if there will be no complains with the new code, it can be removed later.

@raghucssit : can you please attach a screenshot of the preference page? I do not have time to load this patch into IDE, and code reading doesn't replace visual check.

Beside this, I miss one important thing in this PR: the new support should by enabled by default with this preference page, that is one of the main reasons to have the page at all - if the new support breaks something in LSP4E/clients of it, it should be possible to users to fix that without waiting for new release.

[rubenporras]

Hi @raghucssit ,

would it be possible to follow on #1500 (comment)? I think the user should not have this as an option on the UI. It is very hard to make the link between this UI option and copilot, so an user might unclick it and wonder why something breaks, and also, if something is malfunctioning, he will really not know what unchecking this option will do.

[iloveeclipse]

would it be possible to follow on #1500 (comment)? I think the user should not have this as an option on the UI.

The point I have is that the preference management belongs to the plugin who provides the preference.

As I've mentioned above, if there will be another plugin or product that would like to provide access to this preference, we will have multiple places that manage same thing.

It is very hard to make the link between this UI option and copilot,

So should this single option be moved to a "Copilot & Xtext" preferences subtree of "Language Servers" preferences? It would be more clear that it is Copilot related. But I would not consider this as a "Copilot & Xtext only", it is added because of Copilot & Xtext, but it affects all "non-standard" editors and all "document" users of LSP4E.

so an user might unclick it and wonder why something breaks, and also, if something is malfunctioning, he will really not know what unchecking this option will do.

If users "per occasion" click somewhere, they can always click on "Restore defaults" in the preferences.

[rubenporras]

would it be possible to follow on #1500 (comment)? I think the user should not have this as an option on the UI.

The point I have is that the preference management belongs to the plugin who provides the preference.

As I've mentioned above, if there will be another plugin or product that would like to provide access to this preference, we will have multiple places that manage same thing.

Why does it need to be that way? My main point is that we do not need to provide access to this preference in the UI.

It is very hard to make the link between this UI option and copilot,

So should this single option be moved to a "Copilot & Xtext" preferences subtree of "Language Servers" preferences? It would be more clear that it is Copilot related. But I would not consider this as a "Copilot & Xtext only", it is added because of Copilot & Xtext, but it affects all "non-standard" editors and all "document" users of LSP4E.

The default integration of LSP4E is with Platform's Generic and Extensible editor, as announced in the project page. There it is also mentioned "some code may be used as API to let integration be done with other Eclipse-based editors" which I think is the level we should stay on this feature. Maybe a preference was the wrong proposal on my side?