git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Jeff King <peff@peff.net>, Nanako Shiraishi <nanako3@lavabit.com>,
	Teemu Likonen <tlikonen@iki.fi>
Subject: Re: [PATCH v4] graph API: Added logic for colored edges
Date: Sun, 12 Apr 2009 14:59:48 -0700	[thread overview]
Message-ID: <7veivx354b.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20090412202709.GA20549@linux.vnet> (Allan Caffee's message of "Sun, 12 Apr 2009 16:27:09 -0400")

Allan Caffee <allan.caffee@gmail.com> writes:

> I assumed that the +1 in your example was a typo since AFAIKS ARRAY_SIZE
> should give us one past the last index.

You are correct.

> Also if git is to be expanded allow the use of non-ANSI color codes (or
> already does so) the strbuf_escape_sequence_length needs to be updated
> to accept the relevant escape codes.

Actually, I am starting to hate this.

Just step back a bit and imagine how you would do this, if you _were_
writing an application to do this kind of thing, generating output
directly to the terminal.  You obviously would not seek back and count the
width of what you sent out.  Instead,...?

That's right.  You just keep a running total of how much you sent, iow,
what column you expect the current cursor should be.  Can't we do the same
thing here?

> @@ -312,6 +351,33 @@ static struct commit_list *first_interesting_parent(struct git_graph *graph)
>  	return next_interesting_parent(graph, parents);
>  }
>  
> +unsigned short graph_get_current_column_color(const struct git_graph *graph)

static?

> +static void graph_increment_column_color(struct git_graph *graph)
> +{
> +	graph->default_column_color = (graph->default_column_color + 1) %
> +		ARRAY_SIZE(column_colors);

COLUMN_COLORS_MAX?

> +unsigned short graph_find_commit_color(const struct git_graph *graph,
> +				       const struct commit *commit)
> +{

static?

> @@ -714,10 +790,30 @@ static void graph_output_commit_char(struct git_graph *graph, struct strbuf *sb)
>  	strbuf_addch(sb, '*');
>  }
>  
> +void graph_draw_octopus_merge(const struct git_graph *graph,
> +			      struct strbuf *sb)

static?

> @@ -789,6 +880,17 @@ static void graph_output_commit_line(struct git_graph *graph, struct strbuf *sb)
>  		graph_update_state(graph, GRAPH_COLLAPSING);
>  }
>  
> +struct column *find_new_column_by_commit(struct git_graph *graph,
> +					 struct commit *commit)
> +{

static?

> diff --git a/strbuf.c b/strbuf.c
> index a884960..666460d 100644
> --- a/strbuf.c
> +++ b/strbuf.c
> @@ -1,3 +1,4 @@
> +#include <ctype.h>
>  #include "cache.h"
>  #include "refs.h"

BAD.  Do not directly include system headers.  If you need isgraph(),
please support it as part of sane_ctype.  But if you count what you
emitted so far, you would not have to do this at all.

> +/*
> + * Return the length of the escape sequence in a string buffer
> + * starting at index i.  If there is no escape sequence starting at
> + * return 0.
> + */
> +size_t strbuf_esc_sequence_length(const struct strbuf *sb, size_t i)
> +{
> +	size_t start = i;
> +	if (sb->buf[i] != '\033')
> +		return 0;
> +	++i;
> +
> +	if (i >= sb->len || sb->buf[i] != '[')
> +		return 0;
> +	++i;
> +	while (i < sb->len && isdigit(sb->buf[i]))
> +		++i;
> +	if (i >= sb->len || sb->buf[i] != 'm')
> +		return 0;

These preincrements are extremely unreadable at least for me.

	if (sb->buf[i++] != '\033')
        	return 0;
	if (sb->len <= i || sb->buf[i++] != '[')
        	return 0;
	...

But again the point is hopefully moot.

  reply	other threads:[~2009-04-12 22:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090331235922.GA7411@linux.vnet>
2009-04-07 18:57 ` [PATCH] graph API: Added logic for colored edges Allan Caffee
2009-04-08  7:59   ` Junio C Hamano
2009-04-08 21:41     ` Allan Caffee
2009-04-09  0:29       ` Junio C Hamano
2009-04-09 22:22         ` [PATCH v3] " Allan Caffee
2009-04-12  8:44           ` Junio C Hamano
2009-04-12 17:43             ` Allan Caffee
2009-04-12 18:45               ` Junio C Hamano
2009-04-12 20:27                 ` [PATCH v4] " Allan Caffee
2009-04-12 21:59                   ` Junio C Hamano [this message]
2009-04-13 19:53                     ` [PATCH v5] " Allan Caffee
2009-04-09 17:58   ` [PATCH] " Teemu Likonen
2009-04-09 22:08     ` Allan Caffee

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

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

  git send-email \
    --in-reply-to=7veivx354b.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=nanako3@lavabit.com \
    --cc=peff@peff.net \
    --cc=tlikonen@iki.fi \
    /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.
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 NNTP newsgroup(s).