fill-the-blanks: Enhanced diffs for incorrect answer review

[lightmotive]

Hello @ssricardo,

What do you think about enhancing the diffs for wrong answers using Google's Diff-Match-Patch set of modules that are available for Python?

Output Example

Compare Expected content with Actual cnt plus...

• Displayed to user (easy to inline with surrounding content):
  • 

...

[lightmotive]

• Underlying HTML (returned from format_field_result when mismatched):

<del style="background:#ffe6e6;">Expected</del>
<ins style="background:#e6ffe6;">Actual</ins>
<span> c</span>
<del style="background:#ffe6e6;">o</del>
<span>nt</span>
<del style="background:#ffe6e6;">ent</del>
<ins style="background:#e6ffe6;"> plus</ins>

I would be happy to collaborate with you through a patch branch when you have time, e.g.:

• You make the Diff-Match-Patch module (on PyPI) available for import in handler.py.
  • Bundle with add-on?
• I update handler.py to import and use the Diff methods (API; would probably use the diff_main method and the diff_prettyHTML method at least as a reference) to generate enhanced diff HTML when given != expected.
  • I would also define necessary CSS classes for sensible formatting, retaining existing styling where appropriate.
  • Interactive diff demo here; we would probably use the Semantic Cleanup diff.
• You write/update tests and release.
  • If you needed extra help, I would endeavor to set up a local dev environment specifically for Anki Add-on development (I'm familiar with VS Code Dev Containers and Docker) and help with unit tests, too :smile:. Please let me know if you'd like that level of contribution; if so, I would appreciate any guidance or container-related resources you may already have:
    • Do you have a VS Code Dev Container, or just a Docker container, already defined and documented for your add-on dev purposes?
    • Without your guidance, I would start with the official add-on docs and this guide as references to configure a portable VS Code dev container, which I'd be happy to share via public repo if I can get it to work well.

Thanks for your consideration!

[lightmotive]

Update: I have implemented a DMP-based diff solution that works well for the Multi-Line Type Answer Box add-on. Associated branch: README demonstrates the benefits, including Anki dual-diff vs DMP semantic diff (customized HTML) output comparisons.

Based on the comparisons in that README, would you consider DMP's semantic diff an improvement over Anki's dual-block output? How about semantic diff in this fill-the-blanks add-on in place of the current correct ~~(typed)~~? This add-on would need to use inline formatting and, perhaps, a red/green bottom border. Using a bottom border indicator, we can also retain the original formatting when answered correctly.

Because I liked the approach with type multi-line cards so much, I decided to implement a prototype for fill-the-blanks. Here's a visual overview:

When answered incorrectly

Type Cloze Enhanced Diff Prototype: instead of <b><span style="color: rgb(255, 170, 0);">correct</span> <span style="color: rgb(255, 0, 0);"><strike>(typed)</strike></span></b>, how about <b>{{c1::correct}}</b>?

When answered correctly

Type Cloze Enhanced Diff Prototype: instead of always showing <span style="color: rgb(0, 170, 0);"><b>correct</b></span> answers as <span style="color: rgb(0, 170, 0);">green text</span>, how about using a green bottom border and retaining original formatting? E.g., <b>{{c1::<span style="background-color: rgb(255, 255, 10);">correct</span>}}</b>.

I'll await community feedback and a go-ahead from Ricardo before doing further work on this issue. In the meantime, the prototype code I'm currently using with my daily recall practice is available in my fork's patch-enhanced-diff branch: fill-the-blanks/src.

[ssricardo]

Hey Andre! Thanks for all this! I'm quite busy now, so I might take some days/weeks to check this, ok?! But I'll do it later...

[lightmotive]

Sure, Ricardo, no rush, and thanks for your consideration! I realize this would be a significant change that demands consideration and discussion before moving beyond the prototype. If accepted, significant unit test changes and additions will be necessary (I would help with that if you wish).

The delay will also give me more time to discover potential issues and minor enhancements 🧐