Order of suggestions in Quick Fix

[sub-mersion]

When correcting a word with Quick Fix on say the mistyped 'helol' word, the order of suggestions is

• Add 'helol' to the dictionary
• Hide false positive
• Disable rule
• Use 'hello'

Most of the time, one needs to correct the word rather that mark it as an exception.

I suggest the default order for Quick Fix to be reversed, as in

• Use 'hello'
• Add 'helol' to the dictionary
• Hide false positive
• Disable rule

(but maybe it's vscode who enforces quick fixes in alphabetical order?)

[valentjn]

I think this is a duplicate of #129.

[sub-mersion]

It is similar and I am indeed on macOS where ↑ do not wrap to the end of the context menu.

However, my point is that correcting an obvious mistyped word requires at least one more keystroke after the quick fix trigger — and at least 3 (!) on macOS.
On the other hand adding the mistyped word to the dictionary is the default option and requires none.
It does not feel right that allowing the user to repeat his error afterwards is the default selected action.

Besides, even for Linux / Windows, the ↑ "solution" does not work as soon as there are more than one suggestion in the context menu, since they are sorted by score from top to bottom.

Given that word corrections are so common, I think the quick fix menu should present it first.
It would follow the same logic as sorting the suggestions by score: it would sort the suggested actions by frequency.

[valentjn]

From a UX perspective, you're totally right. But the problem with the example in #129 (comment) (screenshot) remains. I wouldn't expect other entries like Add ... to dictionary after all those Use '...' entries, especially if the Add ... to dictionary is not visible at all. Switching the order depending on the number of entries is probably confusing.

IMO, the ideal solution would be to have nested menus/quick fixes, but this would be an issue for VS Code or LSP.

[valentjn]

I just found out you can assign keyboard shortcuts to specific "kinds" of quick fixes. The kind for Use '...' is quickfix.ltex.acceptSuggestions, so how about adding something like this to your keybindings.json:

  {
    "key": "cmd+shift+q",
    "command": "editor.action.codeAction",
    "args": {
      "kind": "quickfix.ltex.acceptSuggestions"
    }
  }

Then you can press Cmd+Shift+Q at an underlined word (without having to press Cmd+. first). If there is only one suggestion, it will use it without any further keystrokes. If there are multiple suggestions, a context menu will open that only contains the Use '...' quick fixes.

[sub-mersion]

That's neat, it's an improvement 🙂

Except that cmd+shift+q is the default shortcut to close the session on macOS.
I bind it to cmd+;, setting is here for future users

 {
    "key": "cmd+;",
    "command": "editor.action.codeAction",
    "args": {
      "kind": "quickfix.ltex.acceptSuggestions"
    }
 }

[sub-mersion]

I wouldn't expect other entries like Add ... to dictionary after all those Use '...' entries, especially if the Add ... to dictionary is not visible at all.
Switching the order depending on the number of entries is probably confusing.

I understand your point and #129 is indeed a pathological example.

In place of context menus, maybe a viable alternative is to put the Add ... to dictionary and similar entries not at the bottom of the list, but after say the first n top suggestions, with n ~ 4 — if only it is allowed by vscode extension features.

For example It is doam would give

- Use 'dam'
- Use 'foam'
- Use 'doom'
- Use 'dorm'
- Add 'doam' to dictionary
- Hide false positive
- Disable rule
- Use 'roam'
- Use 'loam' 
- ...

While the above keybinding works perfectly for me, I still think the out of the box config should suggest corrections before exceptions.

[valentjn]

I've come to the conclusion that having more than 5 or so suggestions is already bad UX: If the correct word is not in the top 5, then just fixing the mistake by hand is probably faster than searching for the correct word in a long list. So I'll just truncate the list to this length and reorder the quick fixes.

However, while experimenting, I noticed that VS Code does reorder the quick fixes, at least when computing them for a selection range (could also be the case for the other editors LT_EX is supporting). This means that while I'm trying to fix this, I won't guarantee any order. If it's still wrong then, you have to open an issue over at microsoft/vscode.

[valentjn]

Implemented as explained in my previous comment. Thanks for the suggestion.

[sub-mersion]

Thank you for having rethink this, I think it is the correct fix.
And thank you for this extension in general, keep the nice work! 😄

[valentjn]

Feature released in 10.2.0.