Configure relative priority of built-in comments (ft.lua) and commentstring

[numtostr]

Configure relative priority of built-in comments (ft.lua) and commentstring

[numToStr]

Why not let the user decide whether ft_table or commentstring gets priority (ideally configurable per-filetype?). Letting commentstring have priority would eliminate the need for any integration code at all for nvim-ts-context-commentstring.

I think you are confused regarding the use of nvim-ts-context-commentstring. How letting the user set priority would remove the need for nvim-ts-context-commentstring integration?

[numToStr]

Also, please provide the actual issue that you are facing with the plugin.

[smackesey]

I think you are confused regarding the use of nvim-ts-context-commentstring. How letting the user set priority would remove the need for nvim-ts-context-commentstring integration?

Because nvim-ts-context-commentstring updates commentstring for you during editing. So, if the user were able to configure the plugin to prioritize commentstring over ft.lua for tsx/jsx, then no pre-hook integration would be needed-- just installing nvim-ts-context-commentstring would be enough. When commenting, Comment.nvim would just read the commentstring already set by nvim-ts-context-commentstring.

To illustrate, this is my current (working) pre-hook configuration. All it does is return commentstring:

pre_hook = function(ctx)
  if vim.bo.filetype == 'typescriptreact' then
    return vim.o.commentstring
  end
end

Also, please provide the actual issue that you are facing with the plugin.

Sorry I was unclear, this is a feature request.

[numToStr]

Because nvim-ts-context-commentstring updates commentstring for you during editing.

Yes and No. The integration that is showcased in the readme doesn't update the commentstring. It just returns that string so that it can be used for comment/uncomment.

So, if the user were able to configure the plugin to prioritize commentstring over ft.lua for tsx/jsx, then no pre-hook integration would be needed-- just installing nvim-ts-context-commentstring would be enough.

You would still need to call something to update commentstring (which I don't recommend), hence pre_hook

---

I have already thought of this before making this plugin and IMO updating commentstring every time is just not worth. Why not just use that string instead of updating a editor's setting? If you get my point, then your request for "priority" will look redundant :)

[smackesey]

We're miscommunicating-- I'm not suggesting that Comment.nvim should update commentstring. I'm pointing out that nvim-ts-context-commentstring already updates commentstring, indepedent of anything Comment.nvim does.

You would still need to call something to update commentstring (which I don't recommend), hence pre_hook

You do not-- that's why the pre_hook I posted (much shorter than the recommended integration) already works. It does not update commentstring, because nvim-ts-context-commentstring does it automatically.

[numToStr]

I'm pointing out that nvim-ts-context-commentstring already updates commentstring

This is what I don't recommend because you have an option to use the calculated commentstring which I showed in the readme.

I understand your point but it's the design choice i made with pre_hook and ft_table which I don't intend to change or provide any kind of setting to override that.

---

IMO the integration code b/w both the plugin is way too verbose. And I believe that can be improved (you can talk to it's author). I am also thinking of making a Comment.nvim only jsx integration as a separate plugin but I am lacking motivation XD

[smackesey]

OK, thx for engaging.