Implement add-on using hook instead of monkey patch

[scott2000]

The monkey patch was broken again in the latest beta version of Anki (issue #39), so it had to be fixed again. A better solution would be to use a hook instead of monkey patching, but there is currently no hook available for changing the behavior of Collection.compare_answer. I made a forum post to request this feature.

[chel-ou]

@scott2000 I gave a few thoughts to this problem and I came up with two possible implementation concepts. I’d like to get your opinion before moving forward.

1. Fully replace the result of compare_answer:
A hook filter called reviewer_will_render_compared_answer(compared_answer: str, expected: str, provided: str) would be created. compared_answer being the result of Anki compare_answer function.
answerset plugin would just overwrite the result of compared_answer generated by Anki.

• Benefit of this solution:
  • Easy to implement based on the existing answerset code
• 2 main drawbacks:
  • It cuts the plugin from all future improvements made to the compare_answer default implementation. An example is the recent combining feature.
  • It requires to maintain a complete implementation of the diff feature.

2. Modify the expected and provided values ahead of Anki compare_answer and further tweak the compared_answer:
2 hook filters would be created:

• reviewer_will_compare_answer(expected_provided: tuple[str, str]), which would rewrite expected and provided, before handling it to Anki compare_answer.
• reviewer_will_render_compared_answer(compared_answer: str, expected_initial: str, provided_initial: str), similar to the previous implementation, except it would take as input the values of expected and provided before the modifications by the first filter.

Here are some examples of how this could work based on some of the examples of the documentation:

• expected = "depart, go, leave" and provided="leave, go":

  • the filter reviewer_will_compare_answer would replace expected by "leave, go, depart".
  • Anki diff would only identify the missing part, without indicating a mistake.
  • the filter reviewer_will_render_compared_answer could remove the provided value and the down arrow to keep similar behavior.

• expected = "set in one's/my ways" and provided="set in my ways":

  • the filter reviewer_will_compare_answer would replace expected by "set in my ways".
  • Anki diff would naturally identify it as correct.
  • the filter reviewer_will_render_compared_answer could add a line after the comparison like Other possible answer: set in one's ways.

• Benefits of this solution:

  • Delegates the diffing to Anki,
  • Remains compatible with future Anki development.

• Drawbacks of this solution:

  • Requires significant modification of answerset code,
  • Requires a transition to keep previous implementation for older anki versions.

What would be your take on this?

[scott2000]

These solutions both seem great to me, thanks for working on this!

I would definitely prefer an option that allows overriding the diff algorithm completely and just outputting raw HTML directly from the hook. I think both of these solutions would allow that, since even if the Anki-generated diff is provided as an argument, add-ons would be free to ignore it.

If either of these approaches is implemented, I most likely would opt to continue overriding the HTML for the diff completely, since it would be the most backwards-compatible solution and it wouldn't require a significant change to the implementation.

I'm not sure whether it would be beneficial for me to be able to override the expected/provided tuple before diffing (for approach 2). For instance, in order to find out that set in my ways is the appropriate text to pass as expected, the add-on would probably have to run a diff-like algorithm anyway (because it still needs to pick the option that minimizes the errors in the diff), so it might as well generate the diff HTML at the same time.

However it could still be a nice feature, because an add-on which overrides the diff algorithm could always return ('', '') for the expected/provided tuple to disable the built-in diff for efficiency. I'm sure some other add-ons might also find this feature useful if they make smaller changes to the expected/provided values. For instance, I could imagine an add-on which automatically transliterates text into the Latin alphabet if it detects that the answer was provided in the Latin alphabet.

Overall, I would be happy with either approach, and I would likely override the diff HTML in reviewer_will_render_compared_answer for either approach.

[chel-ou]

Thank you for your quick feedback. I’ll soon initiate the PR in anki and link it here.

[chel-ou]

Link to the #3855 PR in Anki.

[scott2000]

Looks great to me!