In proper typesetting, "widow" words or lines are taken care of with fluid spacing and rewriting. It's a small science in how best to approach that, and you basically take the entire page/chapter into account to avoid them. Rewriting stuff to get rid of them is perfectly natural. I don't see why we don't care about readability to the same extent when programming.
When typesetting code (which is what we are doing when discussing line limits), natural questions to ask are:
1. Why have a line length limit?
2. If there are reasons to have it, what should it be?
3. Should it be in characters or actual width?
It seems that there's no (big) disagreement that we should have a length limit on lines in code. If you are disagreeing, none of the stuff below matters :)
When it comes to what it should be, a limit of 80 has proven to be sufficiently long not to impede development, and is likely just good as any (you get benefits like multiple side-by-side-by-side windows on wide screens, yet you need to break lines more often; you need to factor your code more carefully to avoid too many indentation levels, yet you can't use sufficiently expressive symbol names....).
If you decide on any particular limit (100? 120? 400?), you'll still have cases where you need to break up long lines. The tools argument (grepping and such) is thus rendered moot, because you've got all the same problems, just less frequently (and that's probably scarier, because it'll be easier to miss something when refactoring).
Finally, the question of monospaced fonts is a curious one: unfortunately, I know of no code editor that works well with non-monospaced fonts, so I've never seriously considered not using them, but the only place where I truly care about fixed-spacing is indentation. And since that renders equally in non-monospaced fonts, I'd be willing to get rid of them too ;-)
In my experience proportional fonts look and work better than monospaced in all editors I use (including email clients, messengers, browsers, ebook readers, dictionaries, file managers). In general I would say anything you can say about preferences will be overriden by habit.
When typesetting code (which is what we are doing when discussing line limits), natural questions to ask are:
1. Why have a line length limit?
2. If there are reasons to have it, what should it be?
3. Should it be in characters or actual width?
It seems that there's no (big) disagreement that we should have a length limit on lines in code. If you are disagreeing, none of the stuff below matters :)
When it comes to what it should be, a limit of 80 has proven to be sufficiently long not to impede development, and is likely just good as any (you get benefits like multiple side-by-side-by-side windows on wide screens, yet you need to break lines more often; you need to factor your code more carefully to avoid too many indentation levels, yet you can't use sufficiently expressive symbol names....).
If you decide on any particular limit (100? 120? 400?), you'll still have cases where you need to break up long lines. The tools argument (grepping and such) is thus rendered moot, because you've got all the same problems, just less frequently (and that's probably scarier, because it'll be easier to miss something when refactoring).
Finally, the question of monospaced fonts is a curious one: unfortunately, I know of no code editor that works well with non-monospaced fonts, so I've never seriously considered not using them, but the only place where I truly care about fixed-spacing is indentation. And since that renders equally in non-monospaced fonts, I'd be willing to get rid of them too ;-)