[boost] Re: [program_options] multi-line description patch

From: Bertolt Mildner (Bertolt.Mildner_at_[hidden])
Date: 2004-12-07 13:02:18

>>> Could you clarify this? I could not understand this from the example
>> you've
>>> given.
>>
>> I can try, but don't know if i can get it much clearer than my example
...
>>
>> My intentions behind this feature are:
>> - If tabs are outputted as tabs they may easily destroy the formatting.
>>
>> - It would be nice to indent a paragraph relative to first_column_width.
>>
>> So paragraph formatting works the following way:
>> - All tabs are removed before output.
>>
>> - If the first line of a paragraph should be indented this has to be
done
>>   with one or more spaces. (There is no trimming done in the first
line!)
>>
>> - If a paragraph is spanned across multible lines, following lines are
>>   indented (relative to first_column_width) using the position of the
last
>>   tab in the paragrapth.
>
>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 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.

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 ...

>>> 5.
>>>
>>>    // trimm slice if out of bounds
>>>    if (i + slice > e)
>>>    {
>>>       slice -= 1;
>>>    }
>>>
>>> Why do you do this?
>>
>> The current part (= line) of a paragraph is [i, i + slice].
>> So if i is increased "i + slice" may move beond the end of the
paragraph.
>
>Ok. I guess if "slice = min<....>" were at the top of the loop, I would
not
>be confused by this code -- I though you have to do clipping anyway, not
>only when there's leading whitespace.
>
>BTW, maybe, you can put "slice = " code after "if (!first_line) and remove
>the clipping inside that "if"?

Yup, well spotted! Done.

Thanks,
Bertolt