[KevinH]

Yes, as I explained the last time this came up.

If you store any non-breaking space in a QTextEdit widget (such as Codeview) and ask for the text from the widget it will automatically convert that non-breaking space to a normal space forever losing it. That is why numeric or named entities are always used to represent the non-breaking space in xhtml code in Sigil.

Calibre has worked around this bug by subclassing the entire QTextEdit widget and overloading the routine that converts to text (plaintext) and replacing it with a routine that literally behind the scenes effectively highlights the entire file and copies the highlighted text out instead of using the standard Qt function.

Sigil has no plans to use that approach as leaving non-breaking spaces in entity form makes the most sense since their is no visual difference between a normal space and non-breaking space in most applications (including Sigil) leading to lots of issues down the road (especially for newbies). The use of the entity for a non-breaking space in no way prevents you from using regex in a proper way. If you decide to circumvent the entity encoding using regex and replacing it with the normal character, you end up getting bitten by the Qt bug.

If you simply can not live with non-breaking space as an entity (numeric or named), then use an output plugin to convert them on the fly on the way out of Sigil. If you reload that file in Sigil, it will convert all non-breaking spaces to their numeric or named entity equivalent (depending on epub version).