Add filetype to floating windows

[akinsho]

Hey, just started using this and really enjoying it 👍🏿 . I've got an issue though which is that the code actions menu numbering is being hidden by my relative number autocommands. I'm wondering if these buffers can be given a custom filetype so I can use it as a hook to exclude these windows from my autocommands. Alternatively if you know a better way that these can be ignored inside the floating windows i.e. can something like eventsignore be used to ignore custom user commands etc.

I appreciate this relates to my setup but interestingly I don't see this issue with coc floating windows the code actions one still shows numbers although I think it doesn't use line numbers and those numbers are written into the buffer maybe

[RishabhRD]

@akinsho Good idea. I would do it in some hour later, as I am a little busy. However, I would start by testing your numbering config. It would be easy for me to regenerate if you just post it here. Great idea btw. You made me really interested in your config. :smile:

[akinsho]

@RishabhRD it's a modified version of another plugin that I cut out, since I really hate seeing the number column in special buffers where it isn't useful like the terminal etc.

This is the plugin file and the autoload. The way it works is that I can specify buftypes and filetypes to ignore so it won't affect those windows. In the case of the code action window it's actually doing what I want normally since I usually don't want numbers inside of a floating window but this is one exception but it's hard to target this window

There are loads of plugins like this btw this is just tweaked because it didn't work for a few buffer types I had. E.g. https://github.com/kennykaye/vim-relativity, https://github.com/jeffkreeftmeijer/vim-numbertoggle

[akinsho]

@RishabhRD I might have found a workaround. Neovim recently merged a vim patch that added the win_gettype which will tell you if the opened window is a floating window. So I've disabled my plugin for floats. But an advantage to still adding a FT could be for user customisation e.g.

I might want the windows to be yellow or something so I can do

autocmd! FileType lsputil_codeation highlight guibg=Yellow

[RishabhRD]

Hi @akinsho , sad I got a little late in creating PR :sweat_smile:. However, I made pull request #20 that should work with your use-case. Actually fuzzy finding is supported and is optional in the plugin, hence there are components filetypes are named like:

• lsputil_codeaction_list
• lsputil_codeaction_prompt

Because the same applies to other components, so other filetypes are like:

• lsputil_locations_list
• lsputil_locations_preview
• lsputil_locations_prompt

and

• lsputil_symbols_list
• lsputil_symbols_preview
• lsputil_symbols_prompt

I hope this would make users have better customizability.

Can you confirm if it fits in your use-case or not and if anything is missing in PR?

[akinsho]

Just commented in the PR but tried it for the first filetype and worked well 👍🏿

[akinsho]

@RishabhRD I actually just realised that the line numbering doesn't do anything i.e. in coc when you press the line number it will trigger that code action. I had assumed it worked the same way as in coc that pressing the number would activate the selection at the line number.

This is fully just my opinion but why not make this work in the same way as coc i.e. add the line numbers in text e.g. 1. Import file or 1) Remove import then in the window remap 1-X nnoremap <buffer> 1 lua somemodule.execute_code_action(1) etc.

One thing of note is that numbers over 9 will cause a bug since you wont be able to type 1 -> 0 without triggering 1. I think coc fixed this by increasing ttimeoutlen temporarily so the mapping didnt trigger till 0 was pressed maybe.

For example in flutter you can have up to 12 code actions that you use regularly so being able to just type 9 or 13 is very helpful vs. hitting j 12 times

[RishabhRD]

@akinsho yeah that can be done by doing nnoremap on every option using a loop. However, what's the problem with something like 12G, to directly jump to that line. It should do the same job, without disturbing the local ttimeoutlen. Or using something like 11j. I know this is 2 keypresses more but this also means we can use our regular vim-search using /, etc. Because some people would like to jump using \<count>\<j or k> or using \<count>G. So, it gives them totally normal vim experience.

I don't know this is the right place to discuss it, but coc people have improved their code-actions UI so much. I used it after a long time today. Previously it used to be a down split that accidentally opens the fuzzy mode and was so confusing. I don't know they learned from nvim-lsputils or something, it is a lot better now.

[akinsho]

Yeah sorry I've definitely gone off topic, this issue can be closed which I'll do now. Regarding the number I guess you can do 12J<CR> and tbh I'm not gonna say it's a huge number of key strokes to save although it is 4 vs 2 😅 also you can still use search in the coc buffer but typically I would just open it and press 7 or 12 etc. Anyway that's more of a suggestion/consideration than an issue 👍🏿

[RishabhRD]

@akinsho NP, maybe I am a little biased towards vim behavior. I didn't use coc from a long time that's why I am unaware about its features :sweat_smile:. Some day in a while I would try to code with coc for the full day, because every little improvement makes the product more furnished. And I can't feel the difference while casually using it just for testing (Actually I felt a bit weird while using that feature).

If I feel the difference then, I would add the PR and mention you for notifying. :smiley:

Thanks for such a great help