Bertolt Mildner wrote:
So, the position of tab basically sets a indent level for the remaining lines in the paragraph. Now I understand this. However, I don't like the "last tab takes effect" rule. What if that last tab is on the third line of the paragraph? Maybe, it's clearer (in code and in docs) to allow only one tab in a paragraph and throw otherwise? Or do you have a use case for multiple tabs?
OK, to throw on multiple tabs makes perfect sens. (Any hint on what exception class is suitable?)
I think program_options::error would work.
I also see the problem when the tab happens to be not on the first line.
The problem is that in cases where line_length is queried from the console this may always happen, just set your console to 10 char long lines -> peng. It's the same problem with (first_column_width >= line_length)!
I would prefere to *not* throw in this situations, but only assert on them. I think it would be much better to leave a user with an ill-formatted option description than with only an error msg.
Asserting on run-time condition does not seems reasonable to me ;-) Maybe, the right solution is to silently ignore tabs which are not on the first line of a paragraph?
And probably set the pragraph indent to something like "tab_pos % (line_length - indent)" to prevent problems in the fromat code. The formatting is smashed anyway ...
Yes, formatting is smashed anyway, so ignoring the tabs on the seconds line is a viable option. - Volodya