git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: Git <git@vger.kernel.org>,
	Christian Couder <christian.couder@gmail.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [PATCH v10 04/13] utf8: add function to align a string into given strbuf
Date: Wed, 12 Aug 2015 09:40:52 -0700	[thread overview]
Message-ID: <xmqq37zompd7.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAOLa=ZRL-WV=9Q+_fo7wcbqT7jZVA02oYo8SfDcLrev=qsUvLg@mail.gmail.com> (Karthik Nayak's message of "Wed, 12 Aug 2015 19:11:05 +0530")

Karthik Nayak <karthik.188@gmail.com> writes:

> On Tue, Aug 11, 2015 at 11:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Karthik Nayak <karthik.188@gmail.com> writes:
>>
>>> +void strbuf_utf8_align(struct strbuf *buf, align_type position, unsigned int width,
>>> +                    const char *s)
>>> +{
>>> +     int display_len = utf8_strnwidth(s, strlen(s), 0);
>>> +     int utf8_compenstation = strlen(s) - display_len;
>>
>> compensation, perhaps?  But notice you are running two strlen and
>> then also a call to utf8-strnwidth here already, and then
>>
>
> compensation it is.
> probably have a single strlen() call and set the value to another variable.

That is not what I meant.  If you want to keep the early return of
"doing nothing for an empty string" (which you should *NOT*, by the
way), declare these variables upfront, do the early return and then
call utf8_strnwidth() to compute the value you are going to use,
only when you know you are going to use them.  That is what I meant.

>>> +     if (!strlen(s))
>>> +             return;
>>
>> you return here without doing anything.
>>
>> Worse yet, this logic looks very strange.  If you give it a width of
>> 8 because you want to align like-item on each record at that column,
>> a record with 1-display-column item will be shown in 8-display-column
>> with 7 SP padding (either at the beginning, or at the end, or on
>> both ends to center).  If it happens to be an empty string, the entire
>> 8-display-column disappears.
>>
>> Is that really what you meant to do?  The logic does not make much
>> sense to me, even though the code may implement that logic correctly
>> and clearly.
>
> Not sure what you meant.
> But this does not act on empty strings and that was intentional.

If it is truly intentional, then the design is wrong.  You are
writing a public function that can be called by other people.

Which one makes more sense?  Remember that you are going to have
many callers over time in the course of project in the future.

 (A) The caller is forced to always check the string that he is
     merely passing on, i.e.

	struct strbuf buf = STRBUF_INIT;
        struct strbuf out = STRBUF_INIT;

	fill_some_placeholder(&buf, fmt, args);
        if (buf.len)
        	strbuf_utf8_align(&out, ALIGN_LEFT, 8, buf.buf);
        else
        	strbuf_addchars(&out, ' ', 8);

     only because the callee strbuf_utf8_align() refuses to do the
     trivial work.

 (B) The caller does not have to care, i.e.

	struct strbuf buf = STRBUF_INIT;
        struct strbuf out = STRBUF_INIT;

	fill_some_placeholder(&buf, fmt, args);
       	strbuf_utf8_align(&out, ALIGN_LEFT, 8, buf.buf);

> It
> does not make
> sense to have an alignment on an empty string, where the caller could themselves
> just do a `strbuf_addchars(&buf, " ", width)`.

It simply does not make sense to force the caller to even care.
What they want is a series of lines, whose columns are aligned.

>>> +     if (display_len >= width) {
>>> +             strbuf_addstr(buf, s);
>>> +             return;
>>> +     }
>>
>> Mental note: this function values the information more than
>> presentation; it refuses to truncate (to lose information) and
>> instead accepts jaggy output.  OK.
>
> With regards to its usage in ref-filter, this is needed, don't you think?

That is exactly why I said "OK".

I was primarily trying to lead other reviewers by example,
demonstrating that a review will become more credible if it shows
that the reviewer actually read the patch by explaining the thinking
behind what the code does in his own words.  I see too many "FWIW,
reviewed by me" without indicating if it is "from just a cursory
read it looks nice" or "I fully read and understood it and I agree
with the design choices it makes", which does not help me very much
when queuing a patch.

  reply	other threads:[~2015-08-12 16:41 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-09 14:11 [PATCH v10 00/13] port tag.c to use ref-filter APIs Karthik Nayak
2015-08-09 14:11 ` [PATCH v10 01/13] ref-filter: move `struct atom_value` to ref-filter.c Karthik Nayak
2015-08-09 14:11 ` [PATCH v10 02/13] ref-filter: print output to strbuf for formatting Karthik Nayak
2015-08-11 17:56   ` Junio C Hamano
2015-08-12 13:22     ` Karthik Nayak
2015-08-12 16:29       ` Junio C Hamano
2015-08-12 16:56         ` Karthik Nayak
2015-08-11 18:00   ` Junio C Hamano
2015-08-12 13:22     ` Karthik Nayak
2015-08-09 14:11 ` [PATCH v10 03/13] ref-filter: introduce ref_formatting_state Karthik Nayak
2015-08-11 18:13   ` Junio C Hamano
2015-08-12 13:26     ` Karthik Nayak
2015-08-09 14:11 ` [PATCH v10 04/13] utf8: add function to align a string into given strbuf Karthik Nayak
2015-08-11 18:22   ` Junio C Hamano
2015-08-12 13:41     ` Karthik Nayak
2015-08-12 16:40       ` Junio C Hamano [this message]
2015-08-12 17:10         ` Karthik Nayak
2015-08-13 19:08   ` Eric Sunshine
2015-08-13 20:55     ` Karthik Nayak
2015-08-14 16:06     ` Junio C Hamano
2015-08-15  8:27   ` Duy Nguyen
2015-08-09 14:11 ` [PATCH v10 05/13] ref-filter: implement an `align` atom Karthik Nayak
2015-08-11 18:52   ` Junio C Hamano
2015-08-12 16:24     ` Karthik Nayak
2015-08-12 17:13       ` Junio C Hamano
2015-08-12 20:07         ` Karthik Nayak
2015-08-12 20:24           ` Junio C Hamano
2015-08-14 15:46             ` Karthik Nayak
2015-08-14 17:42               ` Junio C Hamano
2015-08-13 18:26   ` Eric Sunshine
2015-08-13 20:29     ` Karthik Nayak
2015-08-09 14:11 ` [PATCH v10 06/13] ref-filter: add option to filter only tags Karthik Nayak
2015-08-09 14:11 ` [PATCH v10 07/13] ref-filter: support printing N lines from tag annotation Karthik Nayak
2015-08-09 14:11 ` [PATCH v10 08/13] ref-filter: add support to sort by version Karthik Nayak
2015-08-09 14:11 ` [PATCH v10 09/13] ref-filter: add option to match literal pattern Karthik Nayak
2015-08-09 14:11 ` [PATCH v10 10/13] tag.c: use 'ref-filter' data structures Karthik Nayak
2015-08-09 14:17 ` Karthik Nayak
2015-08-09 14:32 ` [PATCH v10 11/13] tag.c: use 'ref-filter' APIs Karthik Nayak
2015-08-09 14:32 ` [PATCH v10 12/13] tag.c: implement '--format' option Karthik Nayak
2015-08-09 14:32 ` [PATCH v10 13/13] tag.c: implement '--merged' and '--no-merged' options Karthik Nayak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq37zompd7.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).