This is what I came up with towards fixing #39. I don't think that issue is completely solvable, because sometimes that's just what the optimal solution looks like.

I added a test that represents the issue I fixed, which I'll explain here.

The test contains these names:

a
b
ccc
ddd

Now imagine we want to fit them into a width of 6, top-to-bottom and with a filling of 2 spaces. The obvious solution is:

a  ccc
b  ddd

But that's not what the current code does. Instead it tries:

a
b
ccc
ddd

Which succeeds and then it tries:

a    ddd
b
ccc

and fails. The assumption made by the code was that there will be no solution with fewer lines, because we would go on to have more columns, which means more width. But, that assumption was clearly no right.

Regarding changing the code, this means that we cannot break early out of the loop. That in turn means that we have to check every possible number of lines. That's slower, but it gives us another opportunity to optimize: we can check the number of lines starting from 1 instead of theoretical_max_number_of_lines, meaning we can break early again.

I then made a bit of a gamble and relaxed theoretical_max_number_of_lines. I'm guessing that we will now find a solution before we hit that, making it kind of useless in this version. So we should spend less time computing it!

At the risk of doing to much at once, this also clean up of some the code around these computations.