search

slint-ui / slint

Slint is a declarative GUI toolkit to build native user interfaces for Rust, C++, or JavaScript apps.
https://slint.dev
Other
16.94k stars 568 forks source link

LSP uses dashes even if property uses underscores #3935

Closed qarmin closed 8 months ago

qarmin commented 10 months ago

When creating and modifying slint files, I see that lsp always hint to use properties with style property-name instead `property_name.

Screenshot from 2023-11-14 19-23-41

Most programming languages do not allow to use dashes in names, so it is natural for me to use underscores everywhere.

Also rust bindings are using(probably are forced to use) _ everywhere.

I know that current solution was discussed and implemented in https://github.com/slint-ui/slint/issues/382, https://github.com/slint-ui/slint/pull/400, but I don't think that this is optimal.

For now properties in my code are mixed, so refactoring by replacing names of properties is harder, because I need to replace 2 names instead 1.

If defaults cannot not be changed, maybe will be good to add option to allow to choose user a style of names? Or maybe auto completion should use same style like is in property defintion?

Slint-fmt should allow to unify style across codebase.

ogoffart commented 10 months ago

maybe auto completion should use same style like is in property defintion?

I think this makes sense and we should do that.

hunger commented 9 months ago

Root cause is that we treat - and _ as identical characters and normalize towards - while parsing.

I personally find it totally confusing that a_a and a-a are the same identifier and long-term I would like to get rid of that, choosing either _ or - as the "separator character" for use within identifiers in Slint. Short-term it makes sense to push towards the long-term solution, which is what we are doing right now.

I personally would prefer _ as that is what every other language but CSS uses and it plays nice with substractions. I think @qarmin is also in the _ camp ;-) But this is a different discussion to be had for Slint 2.0.