mono/monodevelop — pull request #188 by gary-b (2012-04-01 01:15:53+00:00)
Title: gettext bugs and inefficiencies

This contribution is centred around a problem encountered building master on both Mint 10 and 12, where the PO Editor was rendered unusable by load times in excess of 20 minutes. This was down to a change in the loading routine to rely on a String.Split(string[] ...) overload that was very inefficient on mono (i believe it has since been improved). My original bug submission is here https://bugzilla.xamarin.com/show_bug.cgi?id=2509

My intention is to work through the inefficiencies and bugs in the current implementation of the gettext project, heres what I've got so far....

About Commits "Efficient loading of PO files, better newline detection." and "More Efficient Parsing of PO File":

CatalogParser.cs has been modified, it no longer pre-loads and stores multiple copies of the PO file in memory, both the GetNewLine and Parse methods access the file through a StreamReader.

The new GetNewLine routine is somewhat pedantic in the range it detects, though it matches that set out in the LineSplitStrings member array.

To test the parse routine i opened files, made a small change and saved them. This results in the entire file being rewritten from the contents in memory (i.e. that came from the parse routine). I compared (using a diff tool) the outputted file with that which resulted from performing the exact same operation using the 2.6 version of MonoDevelop, and they matched up. I also created a few simple reference PO files to read in and save.

Though i found no bugs caused by the revised code, i did find some preexisting issues, the main one being in the handling of deleted entries.

If a deleted entry still has a comment proceeding it, the parsing logic reads the whole entry as a comment which then gets added to the next entry in the file (which tends to be a deleted item as these tend to be listed together). When the file is written out, the 2 entries no longer have white space between them and the effect will cascade until the parser only sees a comment and will drop all the deleted items.

The fix was simple enough. See commit "Stopped entire deleted entries being treated as comments in PO files."

About commit "Stopped NRE when PO Editor closed before being fully loaded"

When the user opens a PO file, and proceeds to close it before MonoDevelop has finished its loading process, a NRE occurs. This didn't happen in MD 2.6.

System.NullReferenceException: Object reference not set to an instance of an object
at MonoDevelop.Ide.Gui.Workbench.OpenDocument (FilePath fileName, Int32 line, Int32 column, OpenDocumentOptions options, System.String encoding, IViewDisplayBinding binding) [0x00259]
in /home/garyb/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/Workbench.cs:414

This is caused by the line

doc.RunWhenLoaded (() => doc.Window.SelectWindow ()); in Workbench.cs

added by mkreuger on 29/08/11, in his commit titled "Fixed 'Bug 440 - Can't click buttons without clicking in the text"

Wrapping this in a if (doc != null) check resolves the issue, I have not studied the processes in that routine, the fix SEEMS innocuous enough, please confirm if it will be OK.