Case transformation configuration

[Schottkyc137]

As of 4f20cbd it is possible to enable case transformations for completions. So instead of completing STD_LOGIC_VECTOR, the user can now choose between lower case (std_logic_vector), upper case (STD_LOGIC_VECTOR) or pascal case (Std_Logic_Vector). Yet, for productive use, not all completions should be transformed in the same manner. For example:

• constants are usually upper case constant FOO_BAR : std_logic_vector
• keywords are lower case whereas identifiers are pascal case
• the language server should potentially only change third-party code

I would like to discuss the most suitable configuration option. As an example:

[preferred_case]
# This would contain constants and generics
constant_like = "upper"
keywords = "lower"
# Name subject to change
signals_and_variables = "pascal"

There is also the question as to how granular these options should be. I.e., should it be possible to modify every single keyword? How are multiple categories (i.e., signals and variables) aggregated?

[LDprg]

Here are some thoughts of mine after using this great lsp for a while.

I feel like a way to to this is by using those groups (or something similar):

• constants & generics & block names
• signals & variables names
• file & type names
• keywords
• functions and procedures names
• architecture, entity and package names

However I have some more proposals for the case handling:

Instead of completing names (variables, functions, etc) with the case as defined in the config, there should be a option to use the case as defined in the declaration (with a config like "keep"), while not required for vhdl this feels more natural to me.

In addition to lower, upper and pascal case ther should also be camel case.

Specifying every keyword is probably not needed (at lest for me).

[Schottkyc137]

Thanks a lot for the great input!

• I think constants and generic could be in a constant category (generics are also basically constant). Do you mean block labels with names, i.e., block_name: block is ...? In that case I would make this a new category lables as I usually have lower_snake for this.
• signals & variables could be objects
• file and types could be types although I'm not sure I would put files and types in one category (files are also similar to signals and variables).
• function and procedure names could be subprogram_names
• arch, entity and package names could be unit_names

You can already have the "keep" option if you just omit the preferred_case altogether - this is the standard ;) Or would you prefer to have an explicit "keep" option?

I have also thought about implementing CamelCase - but wasn't sure how to implement this.
As the case transformation may only make single characters lower-or upper case, it's not clear where a separation is (i.e., std_logic_vector may not be StdLogicVector. On the other hand, if you have a string like to_stdlogicvector, it's not obvious that the resulting string should be To_StdLogicVector). Do you have any suggestions on how to handle this?

[ghost]

Hello,

• I fully agree with grouping constants and generics together, they are both constant-like objects. Maybe the name constants_generics is more explicit and intuitive.
• Regarding signals and variables, while objects might feel OOP-oriented, it is actually aligned with the terminology used in the LRM. It also conveniently covers loop parameters so I think this is a good category name.
• For types, I think they should remain in their own dedicated category.
• Files, on the other hand, feel closer to signals and variables in terms of usage patterns, so I would include them in that same category.
• Function and procedure names as subprograms make perfect sense and are consistent with the LRM.
• Entity/architecture/package names as units is a clean and coherent grouping.

Overall, my preference is to stay as close as possible to the LRM terminology.
Concerning keywords, I'm not convinced we need per-keyword configuration, it is better to ensure consistency and avoid unnecessary complexity.
One last point: what about aliases? They probably deserve their own category or inherit the convention of the aliased signal/constant/type?

[Schottkyc137]

I have created a PR in #426 that enables more elaborate overrides with input from this discussion. Any feedback is appreciated!

One last point: what about aliases? They probably deserve their own category or inherit the convention of the aliased signal/constant/type?

This is a very good point. In my PR I have added them as a custom category, but one should think about enabling a "dynamic case" where the casing is forwarded to what the alias actually represents.

[nselvara]

I think the CamelCase question is less about supporting a new preferred style and more about defining deterministic behaviour for mixed inputs.

Even if camelCase or snake_case are not the configured target styles, users will inevitably encounter them in legacy code, autogenerated code, or third-party IP. From a language-server perspective, this makes them valid inputs, even if they are not necessarily intended as normalisation targets.

Personally, I would be cautious about introducing CamelCase as a full transformation mode unless we can clearly define token boundaries. As you pointed out, std_logic_vector → StdLogicVector is already ambiguous, and something like to_stdlogicvector has no obvious canonical CamelCase form.

One possible policy could be:

• lower, upper, and pascal are normalizing modes
• camelCase and snake_case are treated as input patterns, not target styles
• if a transformation cannot be applied unambiguously, the identifier is either kept as-is or explicitly excluded from transformation

This keeps behaviour predictable and avoids heuristics that might surprise users during completion or renaming.

P.S. One last point regarding aliases: I think they should be treated as a distinct category, since they introduce a new identifier in the local scope, even if they ultimately refer to an existing signal, constant, or type.