Am 21.11.2013 00:04, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@xxxxxx> writes:
>> diff --git a/wt-status.c b/wt-status.c
>> index b4e44ba..734f94b 100644
>> --- a/wt-status.c
>> +++ b/wt-status.c
>> @@ -16,6 +16,9 @@
>> #include "column.h"
>> #include "strbuf.h"
>>
>> +static char wt_status_cut_line[] = /* 'X' is replaced with comment_line_char */
>> +"X ------------------------ >8 ------------------------\n";
>> +
>> static char default_wt_status_colors[][COLOR_MAXLEN] = {
>> GIT_COLOR_NORMAL, /* WT_STATUS_HEADER */
>> GIT_COLOR_GREEN, /* WT_STATUS_UPDATED */
>> @@ -767,6 +770,15 @@ conclude:
>> status_printf_ln(s, GIT_COLOR_NORMAL, "");
>> }
>>
>> +void wt_status_truncate_message_at_cut_line(struct strbuf *buf)
>> +{
>> + const char *p;
>> +
>> + p = strstr(buf->buf, wt_status_cut_line);
>> + if (p && (p == buf->buf || p[-1] == '\n'))
>> + strbuf_setlen(buf, p - buf->buf);
>> +}
>
> Perhaps it may happen that all the current callers have called
> wt_status_print_verbose() to cause wt_status_cut_line[0] to hold
> comment_line_char, but relying on that calling sequence somehow
> makes me feel uneasy.
I initialized the place to be occupied by the comment_line_char
in wt_status_cut_line with 'X' on purpose to notice such a
problem. But I'd be also fine with setting wt_status_cut_line[0]
again here just to be sure. But please also see below ...
> Perhaps cut_line[] should only have "--- >8 ---" part and both
> printing side (below) and finding side (this one) should check these
> separately?
... ok ...
> That is:
>
> p = buf->buf;
> while (p && *p) {
> p = strchr(p, comment_line_char);
> if (!p)
> break;
> if (strstr(p + 1, cut_line) == p + 1)
> break;
> p++;
> continue;
> }
> if (p && *p && (p == buf->buf || p[-1] == '\n'))
> strbuf_setlen(buf, p - buf->buf);
>
> or something (the above is deliberately less-efficient-than-ideal,
> because I want to keep the code structure in such a way that we can
> later turn comment_line_char to a string[] that can hold "//" to
> allow a multi-char comment introducer more easily)?
Hmm, I'm a bit reluctant to go that far to optimize this patch for
another one that might materialize later. But what about this:
struct strbuf cut_line = STRBUF_INIT;
strbuf_addf(&cut_line, "%c %s", comment_line_char, wt_status_cut_line);
p = strstr(buf->buf, cut_line.buf);
if (p && (p == buf->buf || p[-1] == '\n'))
strbuf_setlen(buf, p - buf->buf);
strbuf_release(&cut_line);
That is shorter can easily be adapted to a comment line string later.
And even though it's slightly less performant should not be a problem
here as this happens only once after invoking an editor for user input.
>> static void wt_status_print_verbose(struct wt_status *s)
>> {
>> struct rev_info rev;
>> @@ -787,10 +799,17 @@ static void wt_status_print_verbose(struct wt_status *s)
>> * If we're not going to stdout, then we definitely don't
>> * want color, since we are going to the commit message
>> * file (and even the "auto" setting won't work, since it
>> - * will have checked isatty on stdout).
>> + * will have checked isatty on stdout). But we then do want
>> + * to insert the scissor line here to reliably remove the
>> + * diff before committing.
>> */
>> - if (s->fp != stdout)
>> + if (s->fp != stdout) {
>> rev.diffopt.use_color = 0;
>> + wt_status_cut_line[0] = comment_line_char;
>> + fprintf(s->fp, wt_status_cut_line);
>> + fprintf(s->fp, _("%c Do not touch the line above.\n"), comment_line_char);
>> + fprintf(s->fp, _("%c Everything below will be removed.\n"), comment_line_char);
>> + }
>
> I didn't bother with my "how about this" version, but we may want to
> use strbuf_add_commented_lines() to help i18n/l10n folks. Depending
> on the l10n, this message may want to become more or less than 2
> lines.
Makes sense, will change that (maybe using strbuf_commented_addf()
instead) for v4.
--
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