PR: Fix EOL status bug.

[ssoloff]

There were three root causes for the symptoms described in the original issue.

1. Incorrect EOL menu item state

Editor.toggle_eol_chars was being called when the associated widget was both checked and unchecked (apparently, Qt, like most windowing systems, automatically raises a toggled event for the previously selected radio button when a new radio button is toggled). However, toggle_eol_chars appears to assume it is only invoked in the case when the toggled event's checked attribute is True.

When the user selects a new EOL menu item, toggle_eol_chars is invoked twice: once for the radio button being unchecked and once for the radio button being checked. Thus, BaseEditMixin.set_eol_chars is also invoked twice: once with the new EOL and once with the old EOL. set_eol_chars eventually causes the refresh_eol_chars signal to be emitted (via EditorStack.modification_changed). Thus, Editor.refresh_eol_chars is invoked twice with different EOLs. As with toggle_eol_chars, refresh_eol_chars assumes it is only invoked for the new EOL, as evidenced by the fact that it only ever calls setChecked(True) on the associated EOL menu item.

The fix is to ensure toggle_eol_chars only handles the checked case.

2. Stale status bar EOL value

BaseEditMixin.set_eol_chars invokes self.document().setModified(True) before setting self.eol_chars to the new EOL. Setting the document's modified flag causes EditorStack.modification_changed to be invoked synchronously. modification_changed emits the refresh_eol_chars signal based on the current value of self.eol_chars. Because self.eol_chars at this point still references the old EOL, the status bar signal handler uses a stale value to update the UI.

The fix is to ensure self.eol_chars is set to the new EOL before invoking self.document().setModified(True).

3. No EOL menu item updates while document state is modified

BaseEditMixin.set_eol_chars invokes self.document().setModified(True), which subsequently causes a refresh_eol_chars signal to be emitted, which subsequently causes Editor.refresh_eol_chars to be invoked to update the EOL menu item checked state. If the document state is already marked as modified, invoking setModified(True) again does not cause the editor's modificationChanged event to be raised again. Thus, Editor.refresh_eol_chars is not called and the EOL menu items are not updated again until the document state changes from modified to unmodified (e.g. by saving the document).

The fix is to force the document to think its being moved from the unmodified state to the modified state by first calling setModified(False) before calling setModified(True). This smells really bad. Unfortunately, I don't know enough about the Qt API to know if there's a better way to force the refresh_eol_chars signal to be raised in this case. My naive understanding of this part of the code would suggest that it might be better to extract a new method on EditorStack responsible for setting eol_chars. That new method could emit the refresh_eol_chars signal as part of changing the EOL. It seems the emission of that signal should be independent of the document modification state changing. I'm hoping one of the committers can improve this portion of the fix.

[ssoloff]

For #2392.

[ccordoba12]

About your point 3): please follow your own suggestion to:

extract a new method on EditorStack responsible for setting eol_chars

[ccordoba12]

I think it's the cleanest way to implement this :-)

[ssoloff]

Thanks for the review, Carlos. I should have time to make the suggested changes before the end of the weekend.

[ssoloff]

I didn't quite follow the plan I documented in my original commit. After further review, I noted no precedent for BaseEditMixin (or any other mixin) being aware of the editor stack. So I instead decided to add a new signal used to notify interested observers (the editor stack in this case) that the editor's EOL has changed.

Some things I'd appreciate feedback on:

• Not sure if the new method EditorStack.refresh_eol has the best name. I was originally going to name it refresh_eol_chars to be consistent with the other related members throughout the code, but it obviously conflicts with the EditorStack class field of the same name.
• Should EditorStack.refresh_eol accept the EOL chars or the OS name? Using EOL chars is simpler and keeps the responsibility for converting EOL chars to OS name in one place, but it may not be the most logical choice from the domain API perspective.
• Please advise if it is sufficient to add the eol_chars_changed signal field to just TextEditBaseWidget or if the same field must be added to other types that inherit BaseEditMixin (e.g. IPythonControlWidget and IPythonPageControlWidget). I don't believe these types will ever have the BaseEditMixin.set_eol_chars method called.

[ccordoba12]

@rlaverde, please rebase this PR, create a new one with the result and finish it.

[ccordoba12]

Closing in favor #3733.