[Bug]: Questions about forthcoming gnatformat support in ALS

[brownts]

Environment

• OS and Version: N/A
• IDE Version: N/A
• Ada & SPARK Extension Version: N/A

Bug Summary and Reproducer

I have a few questions in anticipation of the inclusion of gnatformat in the ALS:

When I look in settings.md, it says by default this option is enabled. I also noticed in package.json, that the default for VSCode seems to be "true", which matches the description in settings.md. However, when looking in lsp-ada_configurations.ads, it appears the default value in the Configuration type sets Use_Gnatformat to false. Is this a discrepancy or is Use_Gnatformat defaulted to true elsewhere?

Is the expectation that the editor will pull these settings from the project file in order to adjust the its internal indentation and continuation amounts? If so, is there a plan for ALS to support a command for extracting this information from the project file? Also, when useGnatFormat is false, would it also support extracting similar settings from the Pretty_Printer section?

It seems that the settings provided in Format are almost identical to the settings you'd find in .editorconfig. Was there a reason to add a Format section, rather than use an existing .editorconfig?

Configuration and Logs

N/A

Other VS Code Extensions

No response

Additional context

No response

[simonjwright]

The code base for ALS includes gnatformat (certainly as of release 25.0.20241014), and as you can see from #1217 the fact that names are getting title-cased implies that at least --name-mixed-case is being read via the GPR.

[joaopsazevedo]

Hello @brownts.

Is this a discrepancy or is Use_Gnatformat defaulted to true elsewhere?

We want to completely replace GNATpp and any other formatting tool by GNATformat, both in VS Code and GNATstudio, as soon as possible. However, for VSCode that has been done. For GNATstudio, it's a work in progress. Therefore, it was required to have ALS using GNATpp as its default formatter. This is configured here as you correctly noticed.

In VSCode, we added a setting that allows users to control if they want to use GNATformat or GNATpp. By default, this settings is set to use GNATformat. This is done here as you correctly noticed too.

This VSCode setting is sent to ALS through a workspace/didChangeConfiguration notification. Here is the handler, which will override the useGnatformat setting here.

With this mechanism, VS Code by default will use GANTformat (with a setting to change back to GNATpp) and GNAT Studio will continue to use GNATpp for now (it does not send a workspace/didChangeConfiguration notification).

This should explain why there seems to be a discrepancy.

Is the expectation that the editor will pull these settings from the project file in order to adjust the its internal indentation and continuation amounts?

For now, the editors should not pull any settings from the project file (and here I assume you mean the .gpr project file). Everything should be handled by ALS, which indeed reads the project file.

If so, is there a plan for ALS to support a command for extracting this information from the project file?

No, but let us know is there's a use case for it and we will of course consider it.

Also, when useGnatFormat is false, would it also support extracting similar settings from the Pretty_Printer section?

Yes, when useGnatformmat is false, ALS will use GNATpp. GNATpp can be configured through the Pretty_Printer package in your .gpr. GNATformat can also be configured through your .gpr, but it uses the Format package instead. The reason to have different packages is because switches are incompatible between the two and GNATformat does not intend to strictly follow what GNATpp does. See its documentation for more details.

It seems that the settings provided in Format are almost identical to the settings you'd find in .editorconfig. Was there a reason to add a Format section, rather than use an existing .editorconfig?

I guess the reason .editconfig was not considered is because most of our tools are configured through the .gpr. I'll investigate if the use of .editconfig would be beneficial.

The above should answer your questions but feel free ask more if something was not clear.
Thank you for trying GNATformat. Please note that it's still beta and don't be discouraged by style issues. Please report them because contrary to GNATpp, they're significantly easier to fix (usually a matter of minutes instead of hours or even days).

[brownts]

Hi @joaopsazevedo, thanks for the detailed response. Please see my comments below.

Is this a discrepancy or is Use_Gnatformat defaulted to true elsewhere?

We want to completely replace GNATpp and any other formatting tool by GNATformat, both in VS Code and GNATstudio, as soon as possible. However, for VSCode that has been done. For GNATstudio, it's a work in progress. Therefore, it was required to have ALS using GNATpp as its default formatter. This is configured here as you correctly noticed.

In VSCode, we added a setting that allows users to control if they want to use GNATformat or GNATpp. By default, this settings is set to use GNATformat. This is done here as you correctly noticed too.

This VSCode setting is sent to ALS through a workspace/didChangeConfiguration notification. Here is the handler, which will override the useGnatformat setting here.

With this mechanism, VS Code by default will use GANTformat (with a setting to change back to GNATpp) and GNAT Studio will continue to use GNATpp for now (it does not send a workspace/didChangeConfiguration notification).

This should explain why there seems to be a discrepancy.

Yes, this all makes sense, thank you. I'm coming from the perspective of supporting ALS in Emacs and therefore, the reason I'm trying to understand the defaults as set by the server alone. Emacs has two major LSP clients (Eglot and lsp-mode), both of which handle things differently. Eglot will only send a workspace/didChangeConfiguration for explicit user configuration, and lsp-mode will send a workspace/didChangeConfiguration for all boolean configuration options as well as explicit user configuration.

As a result, it seems the documentation with regards to useGnatformat is misleading if using Eglot or GNATStudio, since it doesn't match the ALS defaults. That's fine, as it seems like it is a short-term thing, I was just trying to understand the discrepancy, which you've explained. Additionally, this will let me update the lsp-mode configuration option accordingly.

Is the expectation that the editor will pull these settings from the project file in order to adjust the its internal indentation and continuation amounts?

For now, the editors should not pull any settings from the project file (and here I assume you mean the .gpr project file). Everything should be handled by ALS, which indeed reads the project file.

Yes, I was referring to the .gpr project file. Does "Everything should be handled by ALS" assume that onTypeFormatting is being used? The reason I ask is because Emacs doesn't play well with the ALS onTypeFormatting (see here and here for details). As a result, it is quite common for this to get disabled when using Emacs. Instead of using onTypeFormatting, when I want Emacs to have ALS indent a line, I use textDocument/rangeFormatting instead providing the range for the line and also all of the FormattingOptions. If the editor is using this approach it needs to know what to pass for these options, which can be editor defaults or other settings from somewhere else (such as .editorconfig settings).

If so, is there a plan for ALS to support a command for extracting this information from the project file?

No, but let us know is there's a use case for it and we will of course consider it.

Possibly, see my comment directly above, although I'd much prefer the .editorconfig solution below if possible since it doesn't require the presence of the ALS to get at the settings.

Also, when useGnatFormat is false, would it also support extracting similar settings from the Pretty_Printer section?

Yes, when useGnatformmat is false, ALS will use GNATpp. GNATpp can be configured through the Pretty_Printer package in your .gpr. GNATformat can also be configured through your .gpr, but it uses the Format package instead. The reason to have different packages is because switches are incompatible between the two and GNATformat does not intend to strictly follow what GNATpp does. See its documentation for more details.

This question was really a follow-on to if a new ALS command was created for extracting formatting options from the .gpr file.

It seems that the settings provided in Format are almost identical to the settings you'd find in .editorconfig. Was there a reason to add a Format section, rather than use an existing .editorconfig?

I guess the reason .editconfig was not considered is because most of our tools are configured through the .gpr. I'll investigate if the use of .editconfig would be beneficial.

I think using settings from .editorconfig would be more flexible. Most editors are aware of these configuration files and can automatically handle them to configure themselves. This means, if the settings exist in .editorconfig, editors which aren't using ALS for formatting (or which aren't using onTypeFormatting) can still be configured to format accordingly. If the settings are instead locked away in the .gpr file which most editors don't know about (or where non-trivial parsing of the project file is required in absence of an ALS command to extract them) this makes their use much more difficult.

Please note that it's still beta and don't be discouraged by style issues. Please report them because contrary to GNATpp, they're significantly easier to fix (usually a matter of minutes instead of hours or even days).

Thanks I look forward to giving it a try. Using rangeFormatting with the GNATpp backend seems to have odd behavior sometimes, so I'm hoping GNATformat will be much more behaved in this manner.