unique file extension desireable?

[aserowy]

Hi,

after refining a treesitter implementation (luckasRanarison/tree-sitter-hyprlang) for nvim, we had to work around filetype detection with path logic. A unique file extension for hyprlang files would be way easier to enable highlighting, formatting, even lsp (if there will be one).

Are there any plans to introduce something like *.hypl?

Kind regards
Alexander

[aserowy]

@luckasRanarison fyi

[vaxerski]

no, not really. That would be an annoying breaking change.

[aserowy]

Out of curiosity, why would this be a breaking change?

ps: sry for the double issue, didnt even noticed i created two!?

[vaxerski]

well hyprlang doesn't care about the extension, so I assumed you meant official hypr* apps switching to something like .hypr, in which case people would have to rename their configs, hence, breaking change

[asqarslanov]

If Hyprlang gets its own Tree-sitter grammar, using a unique file extension will allow text editors to easily recognize the file type.

It’s not necessary to force users to rename their config files now. Hyprland may support both *.conf and hypothetical *.hypr. The only changing thing is the default config file name for new users (e.g. init.hypr). Old users can still use the old file extension. The breaking change can be delayed up until v1.0.0.

[aserowy]

That would be awesome! If we could handle extensions for hypr like @asqarslanov suggests.

[aserowy]

Btw. the treesitter spec is here already: https://github.com/luckasRanarison/tree-sitter-hyprlang

Luckas is working on an integration into nvim-treesitter/nvim-treesitter#5852

[vaxerski]

v1.0.0 of what? Neither hyprlang nor hyprland are going to get 1.0, probably ever.

[fufexan]

Can't the grammar be activated by file-types? Something like hyprland.conf, hyprpaper.conf, etc could work, just like here (that's how Helix handles grammars).

[aserowy]

@fufexan
Yeah, this is a path based strategy and we are running an equal filetype pattern match currently.

@vaxerski
Sry for bringing up a valid concern/best practice regarding editor support with a strategy to avoid a breaking change... And no, 1.0.0 was just an example how to handle a finite transition.

[fufexan]

@vaxerski I agree with @aserowy, .conf is way too general to differentiate from other config languages. Let's allow the usage of .hypr/.hy extensions alongside .conf.

[vaxerski]

fwiw in hyprcursor I've used .hl for hyprlang configs