Cloze deletions get shifted by one character
Summary
SuperMemo 17 and later create cloze deletions using raw HTML and do not rely on Internet Explorer. This is why this bug does not occur in the newest versions (dated Mar 1, 2016 or later)
Problem
Gerald M. reported:
I now have used SuperMemo over a year, and I have over 10,000 cards made. Nearly all of the annoyances and glitches in supermemo I have found a work-around for. However, one bug in particular is definitely a bug, and is quite annoying.
TO REPRODUCE :
- Make cards with a lot of text
- Repeatedly doubleclick on words in text to select, then quickly hit alt-Z
The bug is, sometimes a word will be properly selected, yet the card created has the wrong cloze. For instance,
Here's the bug :
SELECT EXAMPLE
This is an example sentence.
Now, sometimes, when you select the word and hit alt-z, the cloze looks like this :
Q: This is an[...]le sentence.
A: example
instead of like this
Q: This is an [...] sentence. A: example
Since the word in the bottom is "example" both times, I know I selected the right text, but supermemo created the cloze wrong.
p.s. The maddening nature of the bug is, I have had it mess up hundreds of cards, yet I was not able to reproduce it when I tried a second ago. I'll eventually figure out exactly how to trigger it, and tell you
Hints
This is a well known and frequently occurring bug. However, it is a problem with Internet Explorer, not SuperMemo. In some contexts, the character count in IE fails (SuperMemo uses the count to know which characters should be replaced with [...]). This happens more often on texts with tables or bullets. This happens more often right after pasting or editing the text.
To have this bug disappear, either the IE bug needs to be fixed, or SuperMemo needs to use a different method of counting characters in HTML (i.e. not relying on IE), or SuperMemo needs to find some workaround (e.g. preventing HTML code snippets, etc.).
Followup
Could you find a work-around for the character count bug if I were to pay for the code change? I don't know how complex it would be to fix, because I've never seen the SuperMemo source code. However, I'm willing to pay $100 american dollars for a fix. Are you interested?
workaround needed
This problem is frequent enough to make it a high priority issue. However, as the bug is in IE, it is hard to find a reliable workaround. We do not charge for bug fixes, but this issue can be documented in more detail and perhaps the answer will come from one of users of SuperMemo (the source code of SuperMemo used in processing HTML is presented here (old version)).
SuperMemo source code
Here is the code where the bug occurs:
TextRange.moveEnd and TextRange.moveStart are functions recommended by Microsoft themselves. However, they tend to return ambiguous results (different character counts on the same texts depending on undetermined factors). Anyone with understanding of DOM scripting in Microsoft products can try to figure out the reasons why those two do not work as designed. Perhaps a workaround can be found then.
technical
If you do JavaScript and DOM with IE then you might (theoretically) solve the problem. However, I suspect the way it is done in SM is the recommended way. It is TextRange.MoveStart/MoveEnd. It just productes different results.
This is how cloze works:
- GetSelection (to see what is selected in SM) - Result A
- Duplicate element, copy selection to answer, etc. etc.
- Back to original element.
- SetSelection (to reselect what was previously selected) and ...- Result B (different than A) - hence the problem
HTML did not change, numbers did not change, only the outcome of MoveEnd/MoveStart differs
Solution
SuperMemo cloze and extract commands used symmetrical procedures for handling plain texts, RTF texts and HTML texts. Before employing Internet Explorer, SuperMemo used TRichEdit.GetSelection(Start,Length) and SetSelection() procedure. Those have later been adopted for parallel use in HTML. Now this symmetry has been broken and SuperMemo uses the recommended DOM procedures and low-level HTML processing. Most importantly, instead making text replacements based on selections and character counts, it retrieves and marks the selected text with DOM TextRange.Selection and does all the processing from that point on using HTML on its own (i.e. no relying on Internet Explorer). TextRange.Selection is far more reliable than TextRange.MoveEnd. This is why the character shift is less likely. The ultimate confirmation of a bug fix can only be made after the release of the new version when problem reports stop.
Answer
This bug will be gone in the future. It is caused by an error in character count returned by Internet Explorer.
see also: