search

tummykung / soylent

Automatically exported from code.google.com/p/soylent
0 stars 0 forks source link

Range/Text changes in document #22

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Submitted text:
Testing, testing, baby!

Patches found:
[[Testing,]] test[[ing, bab]]y!

Fixes made:
removing each patch (though not by clicking it could be removed, simply by
deleting it in the text box).

Results:
After a few slider changes, the document only ever would contain:
y!

Original issue reported on code.google.com by dcrowell...@gmail.com on 4 Jun 2010 at 10:18

GoogleCodeExporter commented 9 years ago 
Another example is attached.  The original text:

In a follow-up to their previous performance tests, long-running, independent 
testing site AV-Comparatives.org loaded up anti-virus and malware prevention 
suites with definition updates from February 2010, but slipped them malware and 
other bad stuff that had been detected and defined since then. This was to test 
the heuristic and analytic powers of these security suites—in other words, to 
see if the software could figure out up-to-the-minute malware, even if their 
providers haven't cataloged them yet in an update, or if the update hasn't hit 
your computer yet.

As you move the slider around, the document gets out of sync with the window.

The database file and js file is attached.

Original comment by esperte...@gmail.com on 9 Jun 2010 at 7:59

Attachments:

GoogleCodeExporter commented 9 years ago 
So annoying, but rather fixable. The problem is this: if a patch can be cut, 
one of the patch options can be an empty string.  When this occurs, we see the 
problem above.  For example, the first 5 tick marks are for different versions 
of patch 1. The 6th tick mark has the original version of patch 1 and a 
different version of patch 3.  However, the results for this tick mark include 
the smallest version of patch 1 (the empty string) instead of the original 
version.  The reason for this? When patch 1 becomes zero length, patch 2 "eats" 
it.  So when patch 1 is later expanded again, patch 2 encompasses the new text. 
 Then when patch 2 is written, it overwrites the new data (patch1 + patch2) to 
be just patch2.  In this way, patch1 is never again expanded.

Solution: I guess we could include some kind of place-holder indicating "This 
patch can be cut".  This could be "|", " ", or something else.  This is not 
ideal, obviously.  Perhaps we could just make these things temporary, i.e. 
existing only when the ShortnDialog window is open.  Upon window close we could 
remove them?

Original comment by dcrowell...@gmail.com on 15 Jun 2010 at 7:19

GoogleCodeExporter commented 9 years ago 
Waiting on Issue 28 in order to fully test.  The case needing to be tested:

[Patch1][Patch2][Patch3]
Patch1 and 2 are removed.  Then, when Patch1 is replaced with text, not only 
does Patch2's start point need to be moved, but Patch3's as well.

Original comment by dcrowell...@gmail.com on 16 Jun 2010 at 8:16