[question] code action bug

[ievgenii-shepeliuk]

Hello @davidmh

I'm experiencing a bug in "Add %word% to cspell json file" code action.
To be able to provide proper PR, I need some feedback from you regarding this place in code

https://github.com/davidmh/cspell.nvim/blob/main/lua/cspell/code_actions/init.lua#L88

My bug is related to the situation while get_word function returns improper misspelled word,
i.e. that word differs from one detected by cspell.

So my question is, why don't we leverage diagnostic.user_data.misspelled instead ?
In my case that field contains a proper word, detected by cspell.

Can you clarify this, so I'd better understand how to address the bug.

Attaching sample file to reproduce.
test.md

And the screenshot to better explain the issue

[eshepelyuk]

Did some more investigation. The problem goes down to diagnostics creation.
When a line contains non latin (unicode ?) characters - the start and end column attributes of the diagnostics may be broken.

[davidmh]

Hi @eshepelyuk

Looks like that's a long standing problem with null-ls that seems to still live in none-ls, see: jose-elias-alvarez/null-ls.nvim#1630

But there is something we can do to at least fix the code actions in this plugin.

The only reason we pull the word from the buffer using the diagnostic range is because right after we execute the code action, we re-insert the original word into the buffer, only to trigger a new dignostic from cspell.

But as you mention, we can pull the misspelled word from the diagnostics and use that to run the code action. We would still use the word from the diagnostic range for the re-insertion.

That means the diagnostic range will still be wrong, but the code actions will work as expected.

I'll push a fix soon.

We should also forward that null-ls issue to the none-ls maintainers.

[davidmh]

Should be resolved by #33

[eshepelyuk]

Should be resolved by #33

Don't you also need to add user_data extraction here ?

https://github.com/davidmh/cspell.nvim/blob/main/lua/cspell/diagnostics/init.lua#L102

[davidmh]

Why?

That's the matcher for the diagnostics without suggestions, if we don't have suggestions, then we don't have code actions, if we don't have code actions, we don't need the user_data.

[eshepelyuk]

Why?

That's the matcher for the diagnostics without suggestions, if we don't have suggestions, then we don't have code actions, if we don't have code actions, we don't need the user_data.

If we don't have suggestions we still may want to add a word to cspell.json config\custom dictionary, i.e. has one code action

[davidmh]

Ah, good point. I'll push it in a minute.

Upon further inspection, we may not need this at all. This is the scenario I created, having the following diagnostic:

There's no suggestion for that word, but the result is still parsed by matcher that looks for suggestions, which means that it will receive the user_data table.

The only other case I can think of for a diagnostic to be matched by the matcher without user_data is:

In that case, there's no suggestions, but there's also no code actions to add the exception.

If that's not the scenario you were describing, could you recreate what you mean using http://github.com/davidmh/cspell-nvim-minimal-init?

[eshepelyuk]

I dont have reproducible scenarios in mind :(
It was just a common sense suggestion.

What is the difference about those 2 input documents, why cspell output differs ?

[davidmh]

What is the difference about those 2 input documents, why cspell output differs ?

The second one doesn't have the show-suggestions flag in the cspell command.

[eshepelyuk]

What is the difference about those 2 input documents, why cspell output differs ?

The second one doesn't have the show-suggestions flag in the cspell command.

Got the point :)))
Then, can you please add a comment to a source code that 2nd regex parser is used only when code action is not enabled ?

[davidmh]

I'll keep it on deck to add on the next commit fix or feature.