At Leanpub, our position is that authors should manually format their code samples so that we do not need to add line breaks.
Since adding a line break can, in fact, break or change the meaning of code in certain languages, it is very important that the reader know that a line break was automatically added, and that they should type all the code in one line, if that is the case.
This is why we add a backslash "continuation character" at the end of the line, when we automatically break a line to fit it on two lines.
Our position is that when we add a continuation character, the author should think of this as a bug in their book that they should fix. In fact, at some point we may list every code sample where we add continuation characters, and include every one of them in the list of errors and warnings that we provide on book generation.
That said, we do know that we have a way to go in improving our errors and warnings. This is the main reason we haven't done this yet.
If you are a programming book author, just format your code manually so that there are no automatic line breaks.
Yes, this is possible to do, and it's not that bad. I speak from personal experience here: I've written books about Adobe Flex, and I had to have the code under 80 colums. (I think it was about 75 columns, but it was a long time ago.) Now, chances are that MXML code (an XML language for defining Flex user interfaces) typically resulted in a lot longer lines of code (it's XML, after all!) than whatever programming language you are writing about -- and I still wrapped all my code so that there were no automatic line breaks.
If I can do it, so can you. It's not that hard to do, and it's better than any alternative...