Error highlight 243

[sgrieve]

Fixing the issue of error highlighting not persisting on line insertion or deletion, as reported in #243.

Resolved by using a document listener to get changes to a text area, and where there are newlines in those changes, update the dictionary of error lines from the server to reflect the new document structure. For the case of deleted lines it is a bit more messy, as we have to use the keypress listener to record the contents of the text area prior to an edit occurring, and then use the document listener to identify the removed text and then do the same process as with the added text, but decreasing line numbers in the dictionary.

Still to do

• [x] Refactor the code as there is some duplication
• [x] Add in docstrings to the new methods
• [x] Make the code PEP8 compliant

I have found some edge cases where the above did not work properly. These all surround what happens when the cursor is on an error line. Most of this has been fixed in commit 1b75425 but one problem remains.

We need to know when the caret is at the end of a line. Currently if you are at the end of an error line and press return, the error highlighting will move down one line, when it should remain in place.

I have modified the code to contain logic to handle this, but have not been able to make a test for being at the end of a line yet, so this logic is currently set to 1 == 1. Once I figure out this issue it will be a quick switch to add it in place of that logic.

Update

The final commit (b3e1466) fixes the above issues by using the old_text instance variable to allow us to ID the line start and end positions before the most recent edit. This allows us to handle the cases where edits are happening on error lines.

[raquelalegre]

Is this OK to review or still in progress?