On Sun, Aug 9, 2015 at 1:34 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
> On Sun, Aug 9, 2015 at 2:55 AM, Karthik Nayak <karthik.188@xxxxxxxxx> wrote:
>> On Sun, Aug 9, 2015 at 9:12 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>>> On Sat, Aug 8, 2015 at 2:35 AM, Karthik Nayak <karthik.188@xxxxxxxxx> wrote:
>>>> On Fri, Aug 7, 2015 at 8:57 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>>>>> On Wed, Aug 5, 2015 at 2:54 PM, Karthik Nayak <karthik.188@xxxxxxxxx> wrote:
>>>>>> + else if (align->align_type == ALIGN_MIDDLE) {
>>>>>> + int right = (align->align_value - buf_len)/2;
>>>>>> + strbuf_addf(final, "%*s%-*s", align->align_value - right + len,
>>>>>> + value->buf, right, "");
>>>>>
>>>>> An aesthetic aside: When (align_value - buf_len) is an odd number,
>>>>> this implementation favors placing more whitespace to the left of the
>>>>> string, and less to the right. In practice, this often tends to look a
>>>>> bit more awkward than the inverse of placing more whitespace to the
>>>>> right, and less to the left (but that again is subjective).
>>>>
>>>> I know that, maybe we could add an additional padding to even out the value
>>>> given?
>>>
>>> I don't understand your question. I was merely suggesting (purely
>>> subjectively), for the "odd length" case, putting the extra space
>>> after the centered text rather than before it. For instance:
>>>
>>> int left = (align->align_value - buf_len) / 2;
>>> strbuf_addf(final, "%*s%-*s", left, "",
>>> align->align_value - left + len, value->buf);
>>>
>>> or any similar variation which would give the same result.
>>
>> I get this could be done, what I was asking was, Consider given a alignment
>> width of 25 would be better to make that 26 so that we have even padding on
>> both sides. But I don't like the adding of manipulating user given data.
>
> I thought you might be asking that, but wasn't certain. I do agree
> with your conclusion that second-guessing the user is a bad idea, and
> that you should give the user exactly what was requested.
>
In that case I'll be doing what you suggested, thanks :)
>>> That raises another question. Why are 'struct ref_formatting_state',
>>> 'struct align', 'struct atom_value', etc. defined in ref-filter.h at
>>> all? Aren't those private implementation details of ref-filter.c, or
>>> do you expect other code to be using them?
>>
>> I guess struct ref_formatting_state and struct align could be moved to
>> ref-filter.c. About struct atom_value its referenced by ref_array_item()
>> so any reader reading about this, would find it easier if atom_value()
>> is at the same place.
>
> Do you expect callers ever to be manipulating or otherwise accessing
> the atom_value of ref_array_item? If callers have no business mucking
> with atom_value, then one option would be to simply forward declare
> atom_value in the header:
>
> struct atom_value;
>
> struct ref_array_item {
> ...
> struct atom_value *value;
> ...
> };
>
> which makes atom_value opaque to clients of ref-filter. The actual
> declaration of atom_value would then be moved to ref-filter.c, thus
> kept private.
Also the code that this was done in has been excepted into `next`
so either I send a new series for the same, or write a patch just to
move this from ref-filter.h to ref-filter.c. So what would you suggest?
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html