git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: James Coglan <jcoglan@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Denton Liu <liu.denton@gmail.com>,
	James Coglan via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 01/11] graph: automatically track visible width of `strbuf`
Date: Sat, 12 Oct 2019 09:27:47 +0900	[thread overview]
Message-ID: <xmqqo8ymg64c.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <79463ee5-a171-53a8-4903-84a825c4e8d8@gmail.com> (James Coglan's message of "Fri, 11 Oct 2019 18:20:43 +0100")

James Coglan <jcoglan@gmail.com> writes:

> - We don't want a general solution to this problem for everything
> `strbuf` could be used for; it only needs to address the graph
> padding problem.

Of course.  Somebody may use strbuf to hold rows of a table and you
do not want to contaminate strbuf with fields like width of each
column etc, that are very specific to the application.  IOW, strbuf
is merely _one_ component of a larger solution to each specific
problem, and the latter may be things like "struct graphbuf" like
Dscho suggested, which might use strbuf as an underlying
<byte-string, length> tuple mechanism, but that is an implementation
detail that should not be exposed to the users of the struct (and
that is why he did not call, and you should not call, the data
structure "graph-strbuf" or anything with "strbuf").

> - We only want to count printing characters, not color formatting sequences.

OK.  But I'd phrase "count printing characters" as "measure display
width" for at least two reasons.  Whitespaces are typically counted
as non-printing, but you do want to take them into account for this
application.  Also the graph may not be limited to ASCII graphics
forever, and byte- or character-count may not match display width on
a fixed-width display.

> - We only need to consider the width of a small set of characters:
> { | / \ _ - . * }. We don't need to worry about Unicode, and the
> simple character counting in graph.c was working fine.

I have to warn you that we saw attempts to step outside these ASCII
graphics and use Unicode characters for prettier output in the past.
If you can do so without too much complexity, I'd suggest you try
not to close the door to those people who follow your footsteps to
further improve the system by pursuing the avenue further.

> To this end I've prepared a different implementation that
> introduces the indirection described above, and does not modify
> `strbuf`:
>
> +struct graph_strbuf {
> +	struct strbuf *buf;
> +	size_t width;
> +};

Is there a reason why you need a pointer to a strbuf that is
allocated separately?  E.g. would it make it harder to manage
if the above were

	struct graphbuf {
		struct strbuf buf;
		int width; /* display width in columns */
	};

which is essentially what Dscho suggested?

> +static inline void graph_strbuf_addch(struct graph_strbuf *sb, int c)
> +{
> +	strbuf_addch(sb->buf, c);
> +	sb->width++;
> +}
> +
> +void graph_strbuf_addchars(struct graph_strbuf *sb, int c, size_t n)
> +{
> +	strbuf_addchars(sb->buf, c, n);
> +	sb->width += n;
> +}
> +
> +static inline void graph_strbuf_addstr(struct graph_strbuf *sb, const char *s)
> +{
> +	strbuf_addstr(sb->buf, s);
> +	sb->width += strlen(s);
> +}

I'd probably introduce another helper that takes color code and
graphbuf (also notice how I name the variables and types; calling
something sb that is not a strbuf is misleading and inviting
unnecessary bugs):

    static inline void graphbuf_addcolor(struct graphbuf *gb, unsigned short color)
    {
            strbuf_addstr(gb->buf, column_get_color_code(color));
    }

if I were writing this code.  The goal is to make any strbuf_add*()
that is done directly on gb->buf outside these helpers a bug--that
way, grepping for strbuf_add* in this file would become a very easy
way to catch such a bug that bypasses the graphbuf_add*() layer and
potentially screw up the column counting.

Other than these three points (i.e. naming without "strbuf" that is
an implementation detail, embedded vs pointer of strbuf in the
graphbuf, and making sure everything can be done via graphbuf_add*()
wrappers to make it easier to spot bugs), it seems you are going in
the right direction.  Thanks for working on this.

  reply	other threads:[~2019-10-12  0:27 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 16:13 [PATCH 00/11] Improve the readability of log --graph output James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 01/11] graph: automatically track visible width of `strbuf` James Coglan via GitGitGadget
2019-10-10 21:07   ` Johannes Schindelin
2019-10-10 23:05     ` Denton Liu
2019-10-11  0:49       ` Derrick Stolee
2019-10-11  1:42       ` Junio C Hamano
2019-10-11  5:01         ` Denton Liu
2019-10-11 16:02           ` Johannes Schindelin
2019-10-11 17:20             ` James Coglan
2019-10-12  0:27               ` Junio C Hamano [this message]
2019-10-12 16:22                 ` Johannes Schindelin
2019-10-14 12:55                 ` James Coglan
2019-10-14 13:01                   ` James Coglan
2019-10-16  2:15                   ` Junio C Hamano
2019-10-11  1:40     ` Junio C Hamano
2019-10-11 17:08     ` James Coglan
2019-10-10 16:13 ` [PATCH 02/11] graph: reuse `find_new_column_by_commit()` James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 03/11] graph: reduce duplication in `graph_insert_into_new_columns()` James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 04/11] graph: remove `mapping_idx` and `graph_update_width()` James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 06/11] graph: tidy up display of left-skewed merges James Coglan via GitGitGadget
2019-10-10 17:19   ` Derrick Stolee
2019-10-11 16:50     ` James Coglan
2019-10-12  1:36       ` Derrick Stolee
2019-10-14 13:11         ` James Coglan
2019-10-10 16:13 ` [PATCH 05/11] graph: extract logic for moving to GRAPH_PRE_COMMIT state James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 07/11] graph: commit and post-merge lines for left-skewed merges James Coglan via GitGitGadget
2019-10-10 17:49   ` Derrick Stolee
2019-10-11 17:04     ` James Coglan
2019-10-13  6:56       ` Jeff King
2019-10-14 15:38         ` James Coglan
2019-10-14 17:41           ` Derrick Stolee
2019-10-14 20:42           ` Johannes Schindelin
2019-10-10 16:13 ` [PATCH 08/11] graph: rename `new_mapping` to `old_mapping` James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 09/11] graph: smooth appearance of collapsing edges on commit lines James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 10/11] graph: flatten edges that join to their right neighbor James Coglan via GitGitGadget
2019-10-10 16:13 ` [PATCH 11/11] graph: fix coloring of octopus dashes James Coglan via GitGitGadget
2019-10-10 18:16   ` Denton Liu
2019-10-10 18:28     ` Denton Liu
2019-10-13  7:22     ` Jeff King
2019-10-10 17:54 ` [PATCH 00/11] Improve the readability of log --graph output Derrick Stolee
2019-10-13  7:15 ` Jeff King
2019-10-14 15:49   ` James Coglan
2019-10-15 23:40 ` [PATCH v2 00/13] " James Coglan via GitGitGadget
2019-10-15 23:40   ` [PATCH v2 01/13] graph: automatically track display width of graph lines James Coglan via GitGitGadget
2019-10-15 23:40   ` [PATCH v2 02/13] graph: handle line padding in `graph_next_line()` James Coglan via GitGitGadget
2019-10-15 23:40   ` [PATCH v2 03/13] graph: reuse `find_new_column_by_commit()` James Coglan via GitGitGadget
2019-10-15 23:40   ` [PATCH v2 04/13] graph: reduce duplication in `graph_insert_into_new_columns()` James Coglan via GitGitGadget
2019-10-15 23:40   ` [PATCH v2 05/13] graph: remove `mapping_idx` and `graph_update_width()` James Coglan via GitGitGadget
2019-10-15 23:40   ` [PATCH v2 06/13] graph: extract logic for moving to GRAPH_PRE_COMMIT state James Coglan via GitGitGadget
2019-10-15 23:40   ` [PATCH v2 07/13] graph: example of graph output that can be simplified James Coglan via GitGitGadget
2019-10-15 23:40   ` [PATCH v2 08/13] graph: tidy up display of left-skewed merges James Coglan via GitGitGadget
2019-10-15 23:41   ` [PATCH v2 09/13] graph: commit and post-merge lines for " James Coglan via GitGitGadget
2019-10-15 23:41   ` [PATCH v2 10/13] graph: rename `new_mapping` to `old_mapping` James Coglan via GitGitGadget
2019-10-15 23:41   ` [PATCH v2 11/13] graph: smooth appearance of collapsing edges on commit lines James Coglan via GitGitGadget
2019-10-15 23:41   ` [PATCH v2 12/13] graph: flatten edges that fuse with their right neighbor James Coglan via GitGitGadget
2019-10-15 23:41   ` [PATCH v2 13/13] graph: fix coloring of octopus dashes James Coglan via GitGitGadget
2019-10-15 23:47   ` [PATCH v3 00/13] Improve the readability of log --graph output James Coglan via GitGitGadget
2019-10-15 23:47     ` [PATCH v3 01/13] graph: automatically track display width of graph lines James Coglan via GitGitGadget
2019-10-16  3:35       ` Junio C Hamano
2019-10-16  5:10         ` Junio C Hamano
2019-10-15 23:47     ` [PATCH v3 02/13] graph: handle line padding in `graph_next_line()` James Coglan via GitGitGadget
2019-10-16  3:37       ` Junio C Hamano
2019-10-15 23:47     ` [PATCH v3 03/13] graph: reuse `find_new_column_by_commit()` James Coglan via GitGitGadget
2019-10-15 23:47     ` [PATCH v3 04/13] graph: reduce duplication in `graph_insert_into_new_columns()` James Coglan via GitGitGadget
2019-10-15 23:47     ` [PATCH v3 05/13] graph: remove `mapping_idx` and `graph_update_width()` James Coglan via GitGitGadget
2019-10-15 23:47     ` [PATCH v3 06/13] graph: extract logic for moving to GRAPH_PRE_COMMIT state James Coglan via GitGitGadget
2019-10-15 23:47     ` [PATCH v3 07/13] graph: example of graph output that can be simplified James Coglan via GitGitGadget
2019-10-17 12:30       ` Derrick Stolee
2019-10-18 15:21       ` SZEDER Gábor
2019-11-12  1:08         ` [PATCH] t4215: don't put git commands upstream of pipe Denton Liu
2019-11-12  6:57           ` Junio C Hamano
2019-11-12 10:54             ` SZEDER Gábor
2019-11-12 18:56           ` [PATCH v3] t4215: use helper function to check output Denton Liu
2019-11-13  2:05             ` Junio C Hamano
2019-10-15 23:47     ` [PATCH v3 08/13] graph: tidy up display of left-skewed merges James Coglan via GitGitGadget
2019-10-16  4:00       ` Junio C Hamano
2019-10-17 12:34         ` Derrick Stolee
2019-10-18  0:49           ` Junio C Hamano
2019-10-15 23:47     ` [PATCH v3 09/13] graph: commit and post-merge lines for " James Coglan via GitGitGadget
2019-10-15 23:47     ` [PATCH v3 10/13] graph: rename `new_mapping` to `old_mapping` James Coglan via GitGitGadget
2019-10-15 23:47     ` [PATCH v3 11/13] graph: smooth appearance of collapsing edges on commit lines James Coglan via GitGitGadget
2019-10-15 23:47     ` [PATCH v3 12/13] graph: flatten edges that fuse with their right neighbor James Coglan via GitGitGadget
2019-10-15 23:47     ` [PATCH v3 13/13] graph: fix coloring of octopus dashes James Coglan via GitGitGadget

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=xmqqo8ymg64c.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jcoglan@gmail.com \
    --cc=liu.denton@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).