Certain filetype not available to register snippets?

[sharpchen]

I added a custom filetype axaml.cs and dedicated snippets for this filetype.

I've done

• register filetype using vim.filetype.add
• add axaml.cs.lua snippet source file
• load snippets by lua loader

However those snippets from axaml.cs.lua do not present in my completion list on that filetype.

But I can confirm those snippets are in fact presented in require('luasnip.session.snippet_collection').get_snippets('axaml.cs', 'snippets').

If I changed axaml.cs.lua to cs.lua, so now this should work only for filetype cs(and it did work), but strangely it worked even when the filetype is axaml.cs (how?)

axaml.cs.lua

local ls = require('luasnip')
local snip = ls.snippet --[[@as fun(trigger: string | { trig: string, name: string, desc: string }, node: any[] | any)]]
local ins = ls.insert_node --[[@as fun(idx: integer, placeholder: string)]]
local fn = ls.function_node
local fmt = require('luasnip.extras.fmt').fmt --[[@as fun(body: string, nodes: any[] | any, opts?: table)]]
local rep = require('luasnip.extras').rep --[[@as fun(idx: integer)]]

local function classname()
  local cursor_node = vim.treesitter.get_node { ignore_injections = false }
  if not cursor_node then return nil end
  local parent = cursor_node:parent()
  while parent and parent:type() ~= 'class_declaration' do
    parent = parent:parent()
  end
  if not parent then return nil end
  local classname_node = parent:field('name')[1]
  if classname_node then
    return vim.treesitter.get_node_text(classname_node, 0)
  else
    return nil
  end
end

local function pascal2camel(name)
  local words = {}
  for word in name:gmatch('%u%l+') do
    table.insert(words, word)
  end
  local is_pascal = table.concat(words):len() == name:len()
  if is_pascal then
    local first = words[1]
    return first:lower() .. table.concat(vim.list_slice(words, 2))
  else
    return name
  end
end

return {
  snip(
    'directProperty',
    fmt(
      [[
    private {propertyType} _{};

    public static readonly DirectProperty<{controlType}, {propertyType}> {}Property = AvaloniaProperty.RegisterDirect<{controlType}, {propertyType}>(
        nameof({}), o => o.{}, (o, v) => o.{} = v);

    public {propertyType} {}
    {{
        get => _{};
        set => SetAndRaise({}Property, ref _{}, value);
    }}
      ]],
      {
        propertyType = ins(2, 'propertyType'),
        controlType = fn(function() return classname() or 'controlType' end),
        fn(function(args)
          -- return require('utils.text').case.convert(args[1][1] or '', 'camel')
          return pascal2camel(args[1][1] or '')
        end, { 1 }),
        ins(1, 'PropertyName'),
        rep(1),
        rep(1),
        rep(1),
        rep(1),
        fn(function(args)
          -- return require('utils.text').case.convert(args[1][1] or '', 'camel')
          return pascal2camel(args[1][1] or '')
        end, { 1 }),
        rep(1),
        fn(function(args)
          -- return require('utils.text').case.convert(args[1][1] or '', 'camel')
          return pascal2camel(args[1][1] or '')
        end, { 1 }),
      },
      { repeat_duplicates = true }
    )
  ),
  snip(
    'styledProperty',
    fmt(
      [[
    public static readonly StyledProperty<{propertyType}> {propertyName}Property = AvaloniaProperty.Register<{controlType}, {propertyType}>(
        nameof({propertyName}));

    public {propertyType} {propertyName}
    {{
        get => GetValue({propertyName}Property);
        set => SetValue({propertyName}Property, value);
    }}
  ]],
      {
        propertyName = ins(1, 'propertyName'),
        propertyType = ins(2, 'propertyType'),
        controlType = fn(function() return classname() or 'controlType' end),
      },
      { repeat_duplicates = true }
    )
  ),
}

[L3MON4D3]

Usually a . in a filetype denotes an and of two regular filetypes, so if a file has the filetype axaml.cs luasnip looks up snippets for the filetypes axaml and cs.
Can you remove the dot from this custom filetype? Maybe use axaml_cs?
If that doesn't work for you, what's your usecase? Maybe there's some idiomatic solution

[sharpchen]

Ok didn't know that, for me . just looks better, but I am ok with _