git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* [PATCH 0/1] extend the truncating pretty formats
@ 2022-10-30 18:56 Philip Oakley
  2022-10-30 18:56 ` [PATCH 1/1] pretty-formats: add hard truncation, without ellipsis, options Philip Oakley
                   ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Philip Oakley @ 2022-10-30 18:56 UTC (permalink / raw)
  To: GitList; +Cc: Self, Junio C Hamano, Taylor Blau, NSENGIYUMVA WILBERFORCE

A recent enquiry on the Git-Users list asked for horizontal log graphs
similar to those used in the manual ASCII art graphs. These use single
or double character short strings for commits.

The existing pretty pretty-formats are unable to truncate to single or
double characters because of their use of ellipsis `..`. As a starter,
let's add left and right hard truncation options to the existing
options as a preparatory step for potential `--horizontal` graphs.

It is noted that the  truncation options do not have any tests yet.

Also cc'ing Nsengiyumva who has proposed to look at unifying the 
ref-filter and --pretty formats [1]

--
Philip

To: Git List <git@vger.kernel.org>
Cc: NSENGIYUMVA WILBERFORCE <nsengiyumvawilberforce@gmail.com>
Cc: Taylor Blau <me@ttaylorr.com>
Cc: Junio C Hamano <gitster@pobox.com>


[1] https://lore.kernel.org/git/CA+PPyiE=baAoVkrghE5GQMt984AcaL=XBAQRsVRbN8w7jQA+ig@mail.gmail.com/

Philip Oakley (1):
  pretty-formats: add hard truncation, without ellipsis, options

 Documentation/pretty-formats.txt |  7 ++++---
 pretty.c                         | 18 +++++++++++++++++-
 2 files changed, 21 insertions(+), 4 deletions(-)

-- 
2.38.1.281.g83ef3ded8d


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH 1/1] pretty-formats: add hard truncation, without ellipsis, options
  2022-10-30 18:56 [PATCH 0/1] extend the truncating pretty formats Philip Oakley
@ 2022-10-30 18:56 ` Philip Oakley
  2022-10-30 19:23   ` Taylor Blau
  2022-10-30 21:41 ` [PATCH 0/1] extend the truncating pretty formats Philip Oakley
  2022-11-01 22:57 ` [PATCH v2 " Philip Oakley
  2 siblings, 1 reply; 22+ messages in thread
From: Philip Oakley @ 2022-10-30 18:56 UTC (permalink / raw)
  To: GitList; +Cc: Self, Junio C Hamano, Taylor Blau, NSENGIYUMVA WILBERFORCE

Instead of replacing with "..", replace with the empty string "",
having adjusted the padding length calculation.

Needswork:
There are no tests for these pretty formats, before or after
this change.

Signed-off-by: Philip Oakley <philipoakley@iee.email>
---
 Documentation/pretty-formats.txt |  7 ++++---
 pretty.c                         | 18 +++++++++++++++++-
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 0b4c1c8d98..bd1657c032 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -146,14 +146,15 @@ The placeholders are:
 '%m':: left (`<`), right (`>`) or boundary (`-`) mark
 '%w([<w>[,<i1>[,<i2>]]])':: switch line wrapping, like the -w option of
 			    linkgit:git-shortlog[1].
-'%<(<N>[,trunc|ltrunc|mtrunc])':: make the next placeholder take at
+'%<(<N>[,trunc|ltrunc|mtrunc|Trunc|Ltrunc])':: make the next placeholder take at
 				  least N columns, padding spaces on
 				  the right if necessary.  Optionally
-				  truncate at the beginning (ltrunc),
+				  truncate (with ellipsis '..') at the beginning (ltrunc),
 				  the middle (mtrunc) or the end
 				  (trunc) if the output is longer than
-				  N columns.  Note that truncating
+				  N columns.  Note that truncating with ellipsis
 				  only works correctly with N >= 2.
+				  Use (Trunc|Ltrunc) for hard truncation without ellipsis.
 '%<|(<N>)':: make the next placeholder take at least until Nth
 	     columns, padding spaces on the right if necessary
 '%>(<N>)', '%>|(<N>)':: similar to '%<(<N>)', '%<|(<N>)' respectively,
diff --git a/pretty.c b/pretty.c
index 6cb363ae1c..f67844d638 100644
--- a/pretty.c
+++ b/pretty.c
@@ -857,7 +857,9 @@ enum trunc_type {
 	trunc_none,
 	trunc_left,
 	trunc_middle,
-	trunc_right
+	trunc_right,
+	trunc_left_hard,
+	trunc_right_hard
 };
 
 struct format_commit_context {
@@ -1145,6 +1147,10 @@ static size_t parse_padding_placeholder(const char *placeholder,
 				c->truncate = trunc_left;
 			else if (starts_with(start, "mtrunc)"))
 				c->truncate = trunc_middle;
+			else if (starts_with(start, "Ltrunc)"))
+				c->truncate = trunc_left_hard;
+			else if (starts_with(start, "Trunc)"))
+				c->truncate = trunc_right_hard;
 			else
 				return 0;
 		} else
@@ -1743,6 +1749,16 @@ static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */
 					    padding - 2, len - (padding - 2),
 					    "..");
 			break;
+		case trunc_left_hard:
+			strbuf_utf8_replace(&local_sb,
+					    0, len - (padding),
+					    "");
+			break;
+		case trunc_right_hard:
+			strbuf_utf8_replace(&local_sb,
+					    padding, len - (padding),
+					    "");
+			break;
 		case trunc_none:
 			break;
 		}
-- 
2.38.1.281.g83ef3ded8d


^ permalink raw reply related	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/1] pretty-formats: add hard truncation, without ellipsis, options
  2022-10-30 18:56 ` [PATCH 1/1] pretty-formats: add hard truncation, without ellipsis, options Philip Oakley
@ 2022-10-30 19:23   ` Taylor Blau
  2022-10-30 22:01     ` Philip Oakley
  0 siblings, 1 reply; 22+ messages in thread
From: Taylor Blau @ 2022-10-30 19:23 UTC (permalink / raw)
  To: Philip Oakley
  Cc: GitList, Junio C Hamano, Taylor Blau, NSENGIYUMVA WILBERFORCE

On Sun, Oct 30, 2022 at 06:56:14PM +0000, Philip Oakley wrote:
> Instead of replacing with "..", replace with the empty string "",
> having adjusted the padding length calculation.
>
> Needswork:
> There are no tests for these pretty formats, before or after
> this change.

Hmmph. I see some when searching for l?trunc in
t4205-log-pretty-formats.sh. Is that coverage not sufficient for the
existing feature?

If so, it would be nice to see it bulked up to add coverage where we
are missing some. Either way, we should make sure the new code is
covered before continuing.

> @@ -1743,6 +1749,16 @@ static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */
>  					    padding - 2, len - (padding - 2),
>  					    "..");
>  			break;
> +		case trunc_left_hard:
> +			strbuf_utf8_replace(&local_sb,
> +					    0, len - (padding),
> +					    "");
> +			break;
> +		case trunc_right_hard:
> +			strbuf_utf8_replace(&local_sb,
> +					    padding, len - (padding),
> +					    "");
> +			break;

If I remember correctly, strbuf_utf8_replace() supports taking NULL as
its last argument, though upon searching I couldn't find any callers
that behave that way. Can we use that instead of supplying the empty
string? If not, should we drop support for the NULL-as-last-argument?

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 0/1] extend the truncating pretty formats
  2022-10-30 18:56 [PATCH 0/1] extend the truncating pretty formats Philip Oakley
  2022-10-30 18:56 ` [PATCH 1/1] pretty-formats: add hard truncation, without ellipsis, options Philip Oakley
@ 2022-10-30 21:41 ` Philip Oakley
  2022-11-01 22:57 ` [PATCH v2 " Philip Oakley
  2 siblings, 0 replies; 22+ messages in thread
From: Philip Oakley @ 2022-10-30 21:41 UTC (permalink / raw)
  To: GitList; +Cc: Junio C Hamano, Taylor Blau, NSENGIYUMVA WILBERFORCE

On 30/10/2022 18:56, Philip Oakley wrote:
> A recent enquiry on the Git-Users list 

forgot the link
https://groups.google.com/g/git-users/c/ayo_4Sy65TI/m/wRkmrcVWAQAJ

> asked for horizontal log graphs
> similar to those used in the manual ASCII art graphs. These use single
> or double character short strings for commits.
>
> The existing pretty pretty-formats are unable to truncate to single or
> double characters because of their use of ellipsis `..`. As a starter,
> let's add left and right hard truncation options to the existing
> options as a preparatory step for potential `--horizontal` graphs.
>
> It is noted that the  truncation options do not have any tests yet.
>
> Also cc'ing Nsengiyumva who has proposed to look at unifying the 
> ref-filter and --pretty formats [1]
>
> --
> Philip
>
> To: Git List <git@vger.kernel.org>
> Cc: NSENGIYUMVA WILBERFORCE <nsengiyumvawilberforce@gmail.com>
> Cc: Taylor Blau <me@ttaylorr.com>
> Cc: Junio C Hamano <gitster@pobox.com>
>
>
> [1] https://lore.kernel.org/git/CA+PPyiE=baAoVkrghE5GQMt984AcaL=XBAQRsVRbN8w7jQA+ig@mail.gmail.com/
>
> Philip Oakley (1):
>   pretty-formats: add hard truncation, without ellipsis, options
>
>  Documentation/pretty-formats.txt |  7 ++++---
>  pretty.c                         | 18 +++++++++++++++++-
>  2 files changed, 21 insertions(+), 4 deletions(-)
>


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/1] pretty-formats: add hard truncation, without ellipsis, options
  2022-10-30 19:23   ` Taylor Blau
@ 2022-10-30 22:01     ` Philip Oakley
  2022-10-30 23:42       ` Taylor Blau
  0 siblings, 1 reply; 22+ messages in thread
From: Philip Oakley @ 2022-10-30 22:01 UTC (permalink / raw)
  To: Taylor Blau; +Cc: GitList, Junio C Hamano, NSENGIYUMVA WILBERFORCE

On 30/10/2022 19:23, Taylor Blau wrote:
> On Sun, Oct 30, 2022 at 06:56:14PM +0000, Philip Oakley wrote:
>> Instead of replacing with "..", replace with the empty string "",
>> having adjusted the padding length calculation.
>>
>> Needswork:
>> There are no tests for these pretty formats, before or after
>> this change.
> Hmmph. I see some when searching for l?trunc in
> t4205-log-pretty-formats.sh. Is that coverage not sufficient for the
> existing feature?
>
> If so, it would be nice to see it bulked up to add coverage where we
> are missing some. Either way, we should make sure the new code is
> covered before continuing.

No idea how I missed them. Maybe I'd filtered, by accident, the search
by a too narrow list of file types.

Thanks for that pointer.

>> @@ -1743,6 +1749,16 @@ static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */
>>  					    padding - 2, len - (padding - 2),
>>  					    "..");
>>  			break;
>> +		case trunc_left_hard:
>> +			strbuf_utf8_replace(&local_sb,
>> +					    0, len - (padding),
>> +					    "");
>> +			break;
>> +		case trunc_right_hard:
>> +			strbuf_utf8_replace(&local_sb,
>> +					    padding, len - (padding),
>> +					    "");
>> +			break;
> If I remember correctly, strbuf_utf8_replace() supports taking NULL as
> its last argument, though upon searching I couldn't find any callers
> that behave that way. Can we use that instead of supplying the empty
> string? If not, should we drop support for the NULL-as-last-argument?

I wasalso  concerned about zero length strings but my brief look at the
code indicated it could cope with a zero length string.
The last param is `const char *subst`.

I've just relooked at the code and it does have a

     if (subst)
        subst_len = strlen(subst);

so it does look safe to pass NULL, though it would probably cause a
pause for thought for readers, and isn't likely to be that much faster
in these format scenarios.
>
> Thanks,
> Taylor
--
Philip

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/1] pretty-formats: add hard truncation, without ellipsis, options
  2022-10-30 22:01     ` Philip Oakley
@ 2022-10-30 23:42       ` Taylor Blau
  0 siblings, 0 replies; 22+ messages in thread
From: Taylor Blau @ 2022-10-30 23:42 UTC (permalink / raw)
  To: Philip Oakley
  Cc: Taylor Blau, GitList, Junio C Hamano, NSENGIYUMVA WILBERFORCE

On Sun, Oct 30, 2022 at 10:01:47PM +0000, Philip Oakley wrote:
> > If I remember correctly, strbuf_utf8_replace() supports taking NULL as
> > its last argument, though upon searching I couldn't find any callers
> > that behave that way. Can we use that instead of supplying the empty
> > string? If not, should we drop support for the NULL-as-last-argument?
>
> I wasalso  concerned about zero length strings but my brief look at the
> code indicated it could cope with a zero length string.
> The last param is `const char *subst`.
>
> I've just relooked at the code and it does have a
>
>      if (subst)
>         subst_len = strlen(subst);
>
> so it does look safe to pass NULL, though it would probably cause a
> pause for thought for readers, and isn't likely to be that much faster
> in these format scenarios.

I'm not worried at all about speed, I was just wondering if there was a
more designated helper for "truncate these many UTF-8 characters from
the end of a string".

It appears that passing NULL to that argument behaves the same as
passing "", so I was wondering if it would be clearer to use that. But
I'm fine either way. If there are no callers that pass NULL, then we
should consider something like the following:

--- 8< ---
diff --git a/utf8.c b/utf8.c
index de4ce5c0e6..e8813f64fe 100644
--- a/utf8.c
+++ b/utf8.c
@@ -361,10 +361,9 @@ void strbuf_utf8_replace(struct strbuf *sb_src, int pos, int width,
 	char *src = sb_src->buf;
 	char *end = src + sb_src->len;
 	char *dst;
-	int w = 0, subst_len = 0;
+	int w = 0, subst_len;

-	if (subst)
-		subst_len = strlen(subst);
+	subst_len = strlen(subst);
 	strbuf_grow(&sb_dst, sb_src->len + subst_len);
 	dst = sb_dst.buf;
--- >8 ---

Below the context there is another "if (subst)", but that one needs to
stay since we only perform the replacement once.

Thanks,
Taylor

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH v2 0/1] extend the truncating pretty formats
  2022-10-30 18:56 [PATCH 0/1] extend the truncating pretty formats Philip Oakley
  2022-10-30 18:56 ` [PATCH 1/1] pretty-formats: add hard truncation, without ellipsis, options Philip Oakley
  2022-10-30 21:41 ` [PATCH 0/1] extend the truncating pretty formats Philip Oakley
@ 2022-11-01 22:57 ` Philip Oakley
  2022-11-01 22:57   ` [PATCH v2 1/1] pretty-formats: add hard truncation, without ellipsis, options Philip Oakley
  2 siblings, 1 reply; 22+ messages in thread
From: Philip Oakley @ 2022-11-01 22:57 UTC (permalink / raw)
  To: GitList; +Cc: Self, Junio C Hamano, Taylor Blau, NSENGIYUMVA WILBERFORCE

Changes since V1.

Added tests for the [L]Trunc in both t/t4205-log-pretty-formats and
t/t6006-rev-list-format matching the existing tests, which I'd missed
before. Thanks to Taylor for point out my error.

Use NULL rather than the empty string "" const which strbuf_utf8_replace
accepts. Also remove unnecessary brackets.

Added suggestive examples for which end of the string are left and right
when truncating, along with middle.

Aside: no attempt at clarifying the potential man page confusion over
`<` in the '%<(<N>[,..` placeholder character sequence and subsequent
entries.

[V1] <20221030185614.3842-1-philipoakley@iee.email> 
A recent enquiry on the Git-Users list asked for horizontal log graphs
similar to those used in the manual ASCII art graphs. These use single
or double character short strings for commits.

The existing pretty pretty-formats are unable to truncate to single or
double characters because of their use of ellipsis `..`. As a starter,
let's add left and right hard truncation options to the existing
options as a preparatory step for potential `--horizontal` graphs.

It is noted that the  truncation options do not have any tests yet.

Also cc'ing Nsengiyumva who has proposed to look at unifying the 
ref-filter and --pretty formats [1]

--
Philip

To: Git List <git@vger.kernel.org>
Cc: NSENGIYUMVA WILBERFORCE <nsengiyumvawilberforce@gmail.com>
Cc: Taylor Blau <me@ttaylorr.com>
Cc: Junio C Hamano <gitster@pobox.com>


[1] https://lore.kernel.org/git/CA+PPyiE=baAoVkrghE5GQMt984AcaL=XBAQRsVRbN8w7jQA+ig@mail.gmail.com/

Philip Oakley (1):
  pretty-formats: add hard truncation, without ellipsis, options

 Documentation/pretty-formats.txt | 11 +++---
 pretty.c                         | 18 ++++++++-
 t/t4205-log-pretty-formats.sh    | 67 ++++++++++++++++++++++++++++++++
 t/t6006-rev-list-format.sh       | 45 +++++++++++++++++++++
 4 files changed, 135 insertions(+), 6 deletions(-)

1:  0f3a12c66c ! 1:  35f83cac94 pretty-formats: add hard truncation, without ellipsis, options
    @@ Documentation/pretty-formats.txt: The placeholders are:
      				  least N columns, padding spaces on
      				  the right if necessary.  Optionally
     -				  truncate at the beginning (ltrunc),
    -+				  truncate (with ellipsis '..') at the beginning (ltrunc),
    - 				  the middle (mtrunc) or the end
    - 				  (trunc) if the output is longer than
    +-				  the middle (mtrunc) or the end
    +-				  (trunc) if the output is longer than
     -				  N columns.  Note that truncating
    ++				  truncate (with ellipsis '..') at the beginning (ltrunc) `..ft`,
    ++				  the middle (mtrunc) `mi..le` or the end
    ++				  (trunc) `rig..` if the output is longer than
     +				  N columns.  Note that truncating with ellipsis
      				  only works correctly with N >= 2.
     +				  Use (Trunc|Ltrunc) for hard truncation without ellipsis.
    @@ pretty.c: static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */
      			break;
     +		case trunc_left_hard:
     +			strbuf_utf8_replace(&local_sb,
    -+					    0, len - (padding),
    -+					    "");
    ++					    0, len - padding,
    ++					    NULL);
     +			break;
     +		case trunc_right_hard:
     +			strbuf_utf8_replace(&local_sb,
    -+					    padding, len - (padding),
    -+					    "");
    ++					    padding, len - padding,
    ++					    NULL);
     +			break;
      		case trunc_none:
      			break;
      		}
    +
    + ## t/t4205-log-pretty-formats.sh ##
    +@@ t/t4205-log-pretty-formats.sh: test_expect_success 'left alignment formatting with trunc' '
    + 	test_cmp expected actual
    + '
    + 
    ++test_expect_success 'left alignment formatting with Trunc' '
    ++	git log --pretty="tformat:%<(10,Trunc)%s" >actual &&
    ++	qz_to_tab_space <<-\EOF >expected &&
    ++	message tw
    ++	message on
    ++	add bar  Z
    ++	initial. a
    ++	EOF
    ++	test_cmp expected actual
    ++'
    ++
    + test_expect_success 'left alignment formatting with trunc. i18n.logOutputEncoding' '
    + 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,trunc)%s" >actual &&
    + 	qz_to_tab_space <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
    +@@ t/t4205-log-pretty-formats.sh: test_expect_success 'left alignment formatting with trunc. i18n.logOutputEncodin
    + 	test_cmp expected actual
    + '
    + 
    ++test_expect_success 'left alignment formatting with Trunc. i18n.logOutputEncoding' '
    ++	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Trunc)%s" >actual &&
    ++	qz_to_tab_space <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
    ++	message tw
    ++	message on
    ++	add bar  Z
    ++	initial. a
    ++	EOF
    ++	test_cmp expected actual
    ++'
    ++
    + test_expect_success 'left alignment formatting with ltrunc' '
    + 	git log --pretty="tformat:%<(10,ltrunc)%s" >actual &&
    + 	qz_to_tab_space <<-EOF >expected &&
    +@@ t/t4205-log-pretty-formats.sh: test_expect_success 'left alignment formatting with ltrunc' '
    + 	test_cmp expected actual
    + '
    + 
    ++test_expect_success 'left alignment formatting with Ltrunc' '
    ++	git log --pretty="tformat:%<(10,Ltrunc)%s" >actual &&
    ++	qz_to_tab_space <<-EOF >expected &&
    ++	essage two
    ++	essage one
    ++	add bar  Z
    ++	an${sample_utf8_part}lich
    ++	EOF
    ++	test_cmp expected actual
    ++'
    ++
    ++
    + test_expect_success 'left alignment formatting with ltrunc. i18n.logOutputEncoding' '
    + 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,ltrunc)%s" >actual &&
    + 	qz_to_tab_space <<-EOF | iconv -f utf-8 -t $test_encoding >expected &&
    +@@ t/t4205-log-pretty-formats.sh: test_expect_success 'left alignment formatting with ltrunc. i18n.logOutputEncodi
    + 	test_cmp expected actual
    + '
    + 
    ++test_expect_success 'left alignment formatting with Ltrunc. i18n.logOutputEncoding' '
    ++	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Ltrunc)%s" >actual &&
    ++	qz_to_tab_space <<-EOF | iconv -f utf-8 -t $test_encoding >expected &&
    ++	essage two
    ++	essage one
    ++	add bar  Z
    ++	an${sample_utf8_part}lich
    ++	EOF
    ++	test_cmp expected actual
    ++'
    + test_expect_success 'left alignment formatting with mtrunc' '
    + 	git log --pretty="tformat:%<(10,mtrunc)%s" >actual &&
    + 	qz_to_tab_space <<-\EOF >expected &&
    +@@ t/t4205-log-pretty-formats.sh: test_expect_success 'left/right alignment formatting with stealing' '
    + 	EOF
    + 	test_cmp expected actual
    + '
    ++
    ++test_expect_success 'left/right hard alignment formatting with stealing' '
    ++	git commit --amend -m short --author "long long long <long@me.com>" &&
    ++	git log --pretty="tformat:%<(10,Trunc)%s%>>(10,Ltrunc)% an" >actual &&
    ++	cat <<-\EOF >expected &&
    ++	short long  long long
    ++	message on   A U Thor
    ++	add bar      A U Thor
    ++	initial. a   A U Thor
    ++	EOF
    ++	test_cmp expected actual
    ++'
    ++
    + test_expect_success 'left/right alignment formatting with stealing. i18n.logOutputEncoding' '
    + 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,trunc)%s%>>(10,ltrunc)% an" >actual &&
    + 	cat <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
    +@@ t/t4205-log-pretty-formats.sh: test_expect_success 'left/right alignment formatting with stealing. i18n.logOutp
    + 	EOF
    + 	test_cmp expected actual
    + '
    ++test_expect_success 'left/right alignment formatting with stealing. i18n.logOutputEncoding' '
    ++	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Trunc)%s%>>(10,Ltrunc)% an" >actual &&
    ++	cat <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
    ++	short long  long long
    ++	message on   A U Thor
    ++	add bar      A U Thor
    ++	initial. a   A U Thor
    ++	EOF
    ++	test_cmp expected actual
    ++'
    + 
    + test_expect_success 'strbuf_utf8_replace() not producing NUL' '
    + 	git log --color --pretty="tformat:%<(10,trunc)%s%>>(10,ltrunc)%C(auto)%d" |
    +
    + ## t/t6006-rev-list-format.sh ##
    +@@ t/t6006-rev-list-format.sh: commit $head1
    + added (hinzugef${added_utf8_part}gt..
    + EOF
    + 
    ++# ZZZ for a space?
    ++test_format subject-truncated "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
    ++commit $head2
    ++changed (ge${changed_utf8_part}ndert) f
    ++commit $head1
    ++added (hinzugef${added_utf8_part}gt)Z
    ++EOF
    ++
    + test_format body %b <<EOF
    + commit $head2
    + commit $head1
    +@@ t/t6006-rev-list-format.sh: commit $head1
    + added (hinzugef${added_utf8_part_iso88591}gt..
    + EOF
    + 
    ++# need qz qz_to_tab_space
    ++test_format complex-subject-Trunc "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
    ++commit $head3
    ++Test printing of com
    ++commit $head2
    ++changed (ge${changed_utf8_part_iso88591}ndert) f
    ++commit $head1
    ++added (hinzugef${added_utf8_part_iso88591}gt)Z
    ++EOF
    ++
    + test_format complex-subject-mtrunc "%<($truncate_count,mtrunc)%s" <<EOF
    + commit $head3
    + Test prin..ex bodies
    +@@ t/t6006-rev-list-format.sh: commit $head1
    + .. (hinzugef${added_utf8_part_iso88591}gt) foo
    + EOF
    + 
    ++test_format complex-subject-Ltrunc "%<($truncate_count,Ltrunc)%s" <<EOF
    ++commit $head3
    ++ng of complex bodies
    ++commit $head2
    ++anged (ge${changed_utf8_part_iso88591}ndert) foo
    ++commit $head1
    ++ed (hinzugef${added_utf8_part_iso88591}gt) foo
    ++EOF
    + test_expect_success 'setup expected messages (for test %b)' '
    + 	cat <<-EOF >expected.utf-8 &&
    + 	commit $head3
    +@@ t/t6006-rev-list-format.sh: commit $head1
    + added (hinzugef${added_utf8_part}gt..
    + EOF
    + 
    ++# need qz_to_tab_space
    ++test_format complex-subject-commitencoding-unset-Trunc "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
    ++commit $head3
    ++Test printing of com
    ++commit $head2
    ++changed (ge${changed_utf8_part}ndert) f
    ++commit $head1
    ++added (hinzugef${added_utf8_part}gt)Z
    ++EOF
    ++
    + test_format complex-subject-commitencoding-unset-mtrunc "%<($truncate_count,mtrunc)%s" <<EOF
    + commit $head3
    + Test prin..ex bodies
    +@@ t/t6006-rev-list-format.sh: commit $head1
    + .. (hinzugef${added_utf8_part}gt) foo
    + EOF
    + 
    ++test_format complex-subject-commitencoding-unset-Ltrunc "%<($truncate_count,Ltrunc)%s" <<EOF
    ++commit $head3
    ++ng of complex bodies
    ++commit $head2
    ++anged (ge${changed_utf8_part}ndert) foo
    ++commit $head1
    ++ed (hinzugef${added_utf8_part}gt) foo
    ++EOF
    ++
    + test_format complex-body-commitencoding-unset %b <expected.utf-8
    + 
    + test_expect_success '%x00 shows NUL' '

-- 
2.38.1.windows.1


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH v2 1/1] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-01 22:57 ` [PATCH v2 " Philip Oakley
@ 2022-11-01 22:57   ` Philip Oakley
  2022-11-01 23:05     ` Philip Oakley
  0 siblings, 1 reply; 22+ messages in thread
From: Philip Oakley @ 2022-11-01 22:57 UTC (permalink / raw)
  To: GitList; +Cc: Self, Junio C Hamano, Taylor Blau, NSENGIYUMVA WILBERFORCE

Instead of replacing with "..", replace with the empty string "",
having adjusted the padding length calculation.

Needswork:
There are no tests for these pretty formats, before or after
this change.

Signed-off-by: Philip Oakley <philipoakley@iee.email>
---
 Documentation/pretty-formats.txt | 11 +++---
 pretty.c                         | 18 ++++++++-
 t/t4205-log-pretty-formats.sh    | 67 ++++++++++++++++++++++++++++++++
 t/t6006-rev-list-format.sh       | 45 +++++++++++++++++++++
 4 files changed, 135 insertions(+), 6 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 0b4c1c8d98..0bd339db33 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -146,14 +146,15 @@ The placeholders are:
 '%m':: left (`<`), right (`>`) or boundary (`-`) mark
 '%w([<w>[,<i1>[,<i2>]]])':: switch line wrapping, like the -w option of
 			    linkgit:git-shortlog[1].
-'%<(<N>[,trunc|ltrunc|mtrunc])':: make the next placeholder take at
+'%<(<N>[,trunc|ltrunc|mtrunc|Trunc|Ltrunc])':: make the next placeholder take at
 				  least N columns, padding spaces on
 				  the right if necessary.  Optionally
-				  truncate at the beginning (ltrunc),
-				  the middle (mtrunc) or the end
-				  (trunc) if the output is longer than
-				  N columns.  Note that truncating
+				  truncate (with ellipsis '..') at the beginning (ltrunc) `..ft`,
+				  the middle (mtrunc) `mi..le` or the end
+				  (trunc) `rig..` if the output is longer than
+				  N columns.  Note that truncating with ellipsis
 				  only works correctly with N >= 2.
+				  Use (Trunc|Ltrunc) for hard truncation without ellipsis.
 '%<|(<N>)':: make the next placeholder take at least until Nth
 	     columns, padding spaces on the right if necessary
 '%>(<N>)', '%>|(<N>)':: similar to '%<(<N>)', '%<|(<N>)' respectively,
diff --git a/pretty.c b/pretty.c
index 6cb363ae1c..1e873d3f41 100644
--- a/pretty.c
+++ b/pretty.c
@@ -857,7 +857,9 @@ enum trunc_type {
 	trunc_none,
 	trunc_left,
 	trunc_middle,
-	trunc_right
+	trunc_right,
+	trunc_left_hard,
+	trunc_right_hard
 };
 
 struct format_commit_context {
@@ -1145,6 +1147,10 @@ static size_t parse_padding_placeholder(const char *placeholder,
 				c->truncate = trunc_left;
 			else if (starts_with(start, "mtrunc)"))
 				c->truncate = trunc_middle;
+			else if (starts_with(start, "Ltrunc)"))
+				c->truncate = trunc_left_hard;
+			else if (starts_with(start, "Trunc)"))
+				c->truncate = trunc_right_hard;
 			else
 				return 0;
 		} else
@@ -1743,6 +1749,16 @@ static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */
 					    padding - 2, len - (padding - 2),
 					    "..");
 			break;
+		case trunc_left_hard:
+			strbuf_utf8_replace(&local_sb,
+					    0, len - padding,
+					    NULL);
+			break;
+		case trunc_right_hard:
+			strbuf_utf8_replace(&local_sb,
+					    padding, len - padding,
+					    NULL);
+			break;
 		case trunc_none:
 			break;
 		}
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index e448ef2928..55dca30798 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -261,6 +261,17 @@ test_expect_success 'left alignment formatting with trunc' '
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Trunc' '
+	git log --pretty="tformat:%<(10,Trunc)%s" >actual &&
+	qz_to_tab_space <<-\EOF >expected &&
+	message tw
+	message on
+	add bar  Z
+	initial. a
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'left alignment formatting with trunc. i18n.logOutputEncoding' '
 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,trunc)%s" >actual &&
 	qz_to_tab_space <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
@@ -272,6 +283,17 @@ test_expect_success 'left alignment formatting with trunc. i18n.logOutputEncodin
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Trunc. i18n.logOutputEncoding' '
+	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Trunc)%s" >actual &&
+	qz_to_tab_space <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
+	message tw
+	message on
+	add bar  Z
+	initial. a
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'left alignment formatting with ltrunc' '
 	git log --pretty="tformat:%<(10,ltrunc)%s" >actual &&
 	qz_to_tab_space <<-EOF >expected &&
@@ -283,6 +305,18 @@ test_expect_success 'left alignment formatting with ltrunc' '
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Ltrunc' '
+	git log --pretty="tformat:%<(10,Ltrunc)%s" >actual &&
+	qz_to_tab_space <<-EOF >expected &&
+	essage two
+	essage one
+	add bar  Z
+	an${sample_utf8_part}lich
+	EOF
+	test_cmp expected actual
+'
+
+
 test_expect_success 'left alignment formatting with ltrunc. i18n.logOutputEncoding' '
 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,ltrunc)%s" >actual &&
 	qz_to_tab_space <<-EOF | iconv -f utf-8 -t $test_encoding >expected &&
@@ -294,6 +328,16 @@ test_expect_success 'left alignment formatting with ltrunc. i18n.logOutputEncodi
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Ltrunc. i18n.logOutputEncoding' '
+	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Ltrunc)%s" >actual &&
+	qz_to_tab_space <<-EOF | iconv -f utf-8 -t $test_encoding >expected &&
+	essage two
+	essage one
+	add bar  Z
+	an${sample_utf8_part}lich
+	EOF
+	test_cmp expected actual
+'
 test_expect_success 'left alignment formatting with mtrunc' '
 	git log --pretty="tformat:%<(10,mtrunc)%s" >actual &&
 	qz_to_tab_space <<-\EOF >expected &&
@@ -507,6 +551,19 @@ test_expect_success 'left/right alignment formatting with stealing' '
 	EOF
 	test_cmp expected actual
 '
+
+test_expect_success 'left/right hard alignment formatting with stealing' '
+	git commit --amend -m short --author "long long long <long@me.com>" &&
+	git log --pretty="tformat:%<(10,Trunc)%s%>>(10,Ltrunc)% an" >actual &&
+	cat <<-\EOF >expected &&
+	short long  long long
+	message on   A U Thor
+	add bar      A U Thor
+	initial. a   A U Thor
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'left/right alignment formatting with stealing. i18n.logOutputEncoding' '
 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,trunc)%s%>>(10,ltrunc)% an" >actual &&
 	cat <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
@@ -517,6 +574,16 @@ test_expect_success 'left/right alignment formatting with stealing. i18n.logOutp
 	EOF
 	test_cmp expected actual
 '
+test_expect_success 'left/right alignment formatting with stealing. i18n.logOutputEncoding' '
+	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Trunc)%s%>>(10,Ltrunc)% an" >actual &&
+	cat <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
+	short long  long long
+	message on   A U Thor
+	add bar      A U Thor
+	initial. a   A U Thor
+	EOF
+	test_cmp expected actual
+'
 
 test_expect_success 'strbuf_utf8_replace() not producing NUL' '
 	git log --color --pretty="tformat:%<(10,trunc)%s%>>(10,ltrunc)%C(auto)%d" |
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 41d0ca00b1..8dcc8000d1 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -218,6 +218,14 @@ commit $head1
 added (hinzugef${added_utf8_part}gt..
 EOF
 
+# ZZZ for a space?
+test_format subject-truncated "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
+commit $head2
+changed (ge${changed_utf8_part}ndert) f
+commit $head1
+added (hinzugef${added_utf8_part}gt)Z
+EOF
+
 test_format body %b <<EOF
 commit $head2
 commit $head1
@@ -400,6 +408,16 @@ commit $head1
 added (hinzugef${added_utf8_part_iso88591}gt..
 EOF
 
+# need qz qz_to_tab_space
+test_format complex-subject-Trunc "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
+commit $head3
+Test printing of com
+commit $head2
+changed (ge${changed_utf8_part_iso88591}ndert) f
+commit $head1
+added (hinzugef${added_utf8_part_iso88591}gt)Z
+EOF
+
 test_format complex-subject-mtrunc "%<($truncate_count,mtrunc)%s" <<EOF
 commit $head3
 Test prin..ex bodies
@@ -418,6 +436,14 @@ commit $head1
 .. (hinzugef${added_utf8_part_iso88591}gt) foo
 EOF
 
+test_format complex-subject-Ltrunc "%<($truncate_count,Ltrunc)%s" <<EOF
+commit $head3
+ng of complex bodies
+commit $head2
+anged (ge${changed_utf8_part_iso88591}ndert) foo
+commit $head1
+ed (hinzugef${added_utf8_part_iso88591}gt) foo
+EOF
 test_expect_success 'setup expected messages (for test %b)' '
 	cat <<-EOF >expected.utf-8 &&
 	commit $head3
@@ -455,6 +481,16 @@ commit $head1
 added (hinzugef${added_utf8_part}gt..
 EOF
 
+# need qz_to_tab_space
+test_format complex-subject-commitencoding-unset-Trunc "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
+commit $head3
+Test printing of com
+commit $head2
+changed (ge${changed_utf8_part}ndert) f
+commit $head1
+added (hinzugef${added_utf8_part}gt)Z
+EOF
+
 test_format complex-subject-commitencoding-unset-mtrunc "%<($truncate_count,mtrunc)%s" <<EOF
 commit $head3
 Test prin..ex bodies
@@ -473,6 +509,15 @@ commit $head1
 .. (hinzugef${added_utf8_part}gt) foo
 EOF
 
+test_format complex-subject-commitencoding-unset-Ltrunc "%<($truncate_count,Ltrunc)%s" <<EOF
+commit $head3
+ng of complex bodies
+commit $head2
+anged (ge${changed_utf8_part}ndert) foo
+commit $head1
+ed (hinzugef${added_utf8_part}gt) foo
+EOF
+
 test_format complex-body-commitencoding-unset %b <expected.utf-8
 
 test_expect_success '%x00 shows NUL' '
-- 
2.38.1.windows.1


^ permalink raw reply related	[flat|nested] 22+ messages in thread

* Re: [PATCH v2 1/1] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-01 22:57   ` [PATCH v2 1/1] pretty-formats: add hard truncation, without ellipsis, options Philip Oakley
@ 2022-11-01 23:05     ` Philip Oakley
  2022-11-02  0:45       ` Taylor Blau
  0 siblings, 1 reply; 22+ messages in thread
From: Philip Oakley @ 2022-11-01 23:05 UTC (permalink / raw)
  To: GitList; +Cc: Junio C Hamano, Taylor Blau, NSENGIYUMVA WILBERFORCE

On 01/11/2022 22:57, Philip Oakley wrote:
> Instead of replacing with "..", replace with the empty string "",
> having adjusted the padding length calculation.
>
> Needswork:
> There are no tests for these pretty formats, before or after
> this change.
>
> Signed-off-by: Philip Oakley <philipoakley@iee.email>
Doh. Too busy doing code and text fixup!'s  to notice the commit message
needed  a tweak.

It's late already so that'll be tomorrow.

Philip

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH v2 1/1] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-01 23:05     ` Philip Oakley
@ 2022-11-02  0:45       ` Taylor Blau
  2022-11-02 12:08         ` [PATCH v3] " Philip Oakley
  0 siblings, 1 reply; 22+ messages in thread
From: Taylor Blau @ 2022-11-02  0:45 UTC (permalink / raw)
  To: Philip Oakley
  Cc: GitList, Junio C Hamano, Taylor Blau, NSENGIYUMVA WILBERFORCE

On Tue, Nov 01, 2022 at 11:05:50PM +0000, Philip Oakley wrote:
> On 01/11/2022 22:57, Philip Oakley wrote:
> > Instead of replacing with "..", replace with the empty string "",
> > having adjusted the padding length calculation.
> >
> > Needswork:
> > There are no tests for these pretty formats, before or after
> > this change.
> >
> > Signed-off-by: Philip Oakley <philipoakley@iee.email>
> Doh. Too busy doing code and text fixup!'s  to notice the commit message
> needed  a tweak.
>
> It's late already so that'll be tomorrow.

It happens. I'll take the new version in the meantime, and await a
reroll from you when you have a chance.

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH v3] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-02  0:45       ` Taylor Blau
@ 2022-11-02 12:08         ` Philip Oakley
  2022-11-12 14:36           ` [PATCH v4] " Philip Oakley
  0 siblings, 1 reply; 22+ messages in thread
From: Philip Oakley @ 2022-11-02 12:08 UTC (permalink / raw)
  To: GitList; +Cc: Self, Junio C Hamano, Taylor Blau, NSENGIYUMVA WILBERFORCE

Instead of truncating with "..", add options to replace with the
empty string, implied by passing NULL, and adjust the padding length calculation.

Extend the existing tests for these pretty formats to include
`Trunc` and Ltrunc` options matching the `trunc` and `ltrunc`
tests.

Signed-off-by: Philip Oakley <philipoakley@iee.email>
---
With updated commit message. No other changes.
---
 Documentation/pretty-formats.txt | 11 +++---
 pretty.c                         | 18 ++++++++-
 t/t4205-log-pretty-formats.sh    | 67 ++++++++++++++++++++++++++++++++
 t/t6006-rev-list-format.sh       | 45 +++++++++++++++++++++
 4 files changed, 135 insertions(+), 6 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 0b4c1c8d98..0bd339db33 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -146,14 +146,15 @@ The placeholders are:
 '%m':: left (`<`), right (`>`) or boundary (`-`) mark
 '%w([<w>[,<i1>[,<i2>]]])':: switch line wrapping, like the -w option of
 			    linkgit:git-shortlog[1].
-'%<(<N>[,trunc|ltrunc|mtrunc])':: make the next placeholder take at
+'%<(<N>[,trunc|ltrunc|mtrunc|Trunc|Ltrunc])':: make the next placeholder take at
 				  least N columns, padding spaces on
 				  the right if necessary.  Optionally
-				  truncate at the beginning (ltrunc),
-				  the middle (mtrunc) or the end
-				  (trunc) if the output is longer than
-				  N columns.  Note that truncating
+				  truncate (with ellipsis '..') at the beginning (ltrunc) `..ft`,
+				  the middle (mtrunc) `mi..le` or the end
+				  (trunc) `rig..` if the output is longer than
+				  N columns.  Note that truncating with ellipsis
 				  only works correctly with N >= 2.
+				  Use (Trunc|Ltrunc) for hard truncation without ellipsis.
 '%<|(<N>)':: make the next placeholder take at least until Nth
 	     columns, padding spaces on the right if necessary
 '%>(<N>)', '%>|(<N>)':: similar to '%<(<N>)', '%<|(<N>)' respectively,
diff --git a/pretty.c b/pretty.c
index 6cb363ae1c..1e873d3f41 100644
--- a/pretty.c
+++ b/pretty.c
@@ -857,7 +857,9 @@ enum trunc_type {
 	trunc_none,
 	trunc_left,
 	trunc_middle,
-	trunc_right
+	trunc_right,
+	trunc_left_hard,
+	trunc_right_hard
 };
 
 struct format_commit_context {
@@ -1145,6 +1147,10 @@ static size_t parse_padding_placeholder(const char *placeholder,
 				c->truncate = trunc_left;
 			else if (starts_with(start, "mtrunc)"))
 				c->truncate = trunc_middle;
+			else if (starts_with(start, "Ltrunc)"))
+				c->truncate = trunc_left_hard;
+			else if (starts_with(start, "Trunc)"))
+				c->truncate = trunc_right_hard;
 			else
 				return 0;
 		} else
@@ -1743,6 +1749,16 @@ static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */
 					    padding - 2, len - (padding - 2),
 					    "..");
 			break;
+		case trunc_left_hard:
+			strbuf_utf8_replace(&local_sb,
+					    0, len - padding,
+					    NULL);
+			break;
+		case trunc_right_hard:
+			strbuf_utf8_replace(&local_sb,
+					    padding, len - padding,
+					    NULL);
+			break;
 		case trunc_none:
 			break;
 		}
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index e448ef2928..55dca30798 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -261,6 +261,17 @@ test_expect_success 'left alignment formatting with trunc' '
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Trunc' '
+	git log --pretty="tformat:%<(10,Trunc)%s" >actual &&
+	qz_to_tab_space <<-\EOF >expected &&
+	message tw
+	message on
+	add bar  Z
+	initial. a
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'left alignment formatting with trunc. i18n.logOutputEncoding' '
 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,trunc)%s" >actual &&
 	qz_to_tab_space <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
@@ -272,6 +283,17 @@ test_expect_success 'left alignment formatting with trunc. i18n.logOutputEncodin
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Trunc. i18n.logOutputEncoding' '
+	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Trunc)%s" >actual &&
+	qz_to_tab_space <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
+	message tw
+	message on
+	add bar  Z
+	initial. a
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'left alignment formatting with ltrunc' '
 	git log --pretty="tformat:%<(10,ltrunc)%s" >actual &&
 	qz_to_tab_space <<-EOF >expected &&
@@ -283,6 +305,18 @@ test_expect_success 'left alignment formatting with ltrunc' '
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Ltrunc' '
+	git log --pretty="tformat:%<(10,Ltrunc)%s" >actual &&
+	qz_to_tab_space <<-EOF >expected &&
+	essage two
+	essage one
+	add bar  Z
+	an${sample_utf8_part}lich
+	EOF
+	test_cmp expected actual
+'
+
+
 test_expect_success 'left alignment formatting with ltrunc. i18n.logOutputEncoding' '
 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,ltrunc)%s" >actual &&
 	qz_to_tab_space <<-EOF | iconv -f utf-8 -t $test_encoding >expected &&
@@ -294,6 +328,16 @@ test_expect_success 'left alignment formatting with ltrunc. i18n.logOutputEncodi
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Ltrunc. i18n.logOutputEncoding' '
+	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Ltrunc)%s" >actual &&
+	qz_to_tab_space <<-EOF | iconv -f utf-8 -t $test_encoding >expected &&
+	essage two
+	essage one
+	add bar  Z
+	an${sample_utf8_part}lich
+	EOF
+	test_cmp expected actual
+'
 test_expect_success 'left alignment formatting with mtrunc' '
 	git log --pretty="tformat:%<(10,mtrunc)%s" >actual &&
 	qz_to_tab_space <<-\EOF >expected &&
@@ -507,6 +551,19 @@ test_expect_success 'left/right alignment formatting with stealing' '
 	EOF
 	test_cmp expected actual
 '
+
+test_expect_success 'left/right hard alignment formatting with stealing' '
+	git commit --amend -m short --author "long long long <long@me.com>" &&
+	git log --pretty="tformat:%<(10,Trunc)%s%>>(10,Ltrunc)% an" >actual &&
+	cat <<-\EOF >expected &&
+	short long  long long
+	message on   A U Thor
+	add bar      A U Thor
+	initial. a   A U Thor
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'left/right alignment formatting with stealing. i18n.logOutputEncoding' '
 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,trunc)%s%>>(10,ltrunc)% an" >actual &&
 	cat <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
@@ -517,6 +574,16 @@ test_expect_success 'left/right alignment formatting with stealing. i18n.logOutp
 	EOF
 	test_cmp expected actual
 '
+test_expect_success 'left/right alignment formatting with stealing. i18n.logOutputEncoding' '
+	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Trunc)%s%>>(10,Ltrunc)% an" >actual &&
+	cat <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
+	short long  long long
+	message on   A U Thor
+	add bar      A U Thor
+	initial. a   A U Thor
+	EOF
+	test_cmp expected actual
+'
 
 test_expect_success 'strbuf_utf8_replace() not producing NUL' '
 	git log --color --pretty="tformat:%<(10,trunc)%s%>>(10,ltrunc)%C(auto)%d" |
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 41d0ca00b1..8dcc8000d1 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -218,6 +218,14 @@ commit $head1
 added (hinzugef${added_utf8_part}gt..
 EOF
 
+# ZZZ for a space?
+test_format subject-truncated "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
+commit $head2
+changed (ge${changed_utf8_part}ndert) f
+commit $head1
+added (hinzugef${added_utf8_part}gt)Z
+EOF
+
 test_format body %b <<EOF
 commit $head2
 commit $head1
@@ -400,6 +408,16 @@ commit $head1
 added (hinzugef${added_utf8_part_iso88591}gt..
 EOF
 
+# need qz qz_to_tab_space
+test_format complex-subject-Trunc "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
+commit $head3
+Test printing of com
+commit $head2
+changed (ge${changed_utf8_part_iso88591}ndert) f
+commit $head1
+added (hinzugef${added_utf8_part_iso88591}gt)Z
+EOF
+
 test_format complex-subject-mtrunc "%<($truncate_count,mtrunc)%s" <<EOF
 commit $head3
 Test prin..ex bodies
@@ -418,6 +436,14 @@ commit $head1
 .. (hinzugef${added_utf8_part_iso88591}gt) foo
 EOF
 
+test_format complex-subject-Ltrunc "%<($truncate_count,Ltrunc)%s" <<EOF
+commit $head3
+ng of complex bodies
+commit $head2
+anged (ge${changed_utf8_part_iso88591}ndert) foo
+commit $head1
+ed (hinzugef${added_utf8_part_iso88591}gt) foo
+EOF
 test_expect_success 'setup expected messages (for test %b)' '
 	cat <<-EOF >expected.utf-8 &&
 	commit $head3
@@ -455,6 +481,16 @@ commit $head1
 added (hinzugef${added_utf8_part}gt..
 EOF
 
+# need qz_to_tab_space
+test_format complex-subject-commitencoding-unset-Trunc "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
+commit $head3
+Test printing of com
+commit $head2
+changed (ge${changed_utf8_part}ndert) f
+commit $head1
+added (hinzugef${added_utf8_part}gt)Z
+EOF
+
 test_format complex-subject-commitencoding-unset-mtrunc "%<($truncate_count,mtrunc)%s" <<EOF
 commit $head3
 Test prin..ex bodies
@@ -473,6 +509,15 @@ commit $head1
 .. (hinzugef${added_utf8_part}gt) foo
 EOF
 
+test_format complex-subject-commitencoding-unset-Ltrunc "%<($truncate_count,Ltrunc)%s" <<EOF
+commit $head3
+ng of complex bodies
+commit $head2
+anged (ge${changed_utf8_part}ndert) foo
+commit $head1
+ed (hinzugef${added_utf8_part}gt) foo
+EOF
+
 test_format complex-body-commitencoding-unset %b <expected.utf-8
 
 test_expect_success '%x00 shows NUL' '
-- 
2.38.1.281.g83ef3ded8d


^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH v4] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-02 12:08         ` [PATCH v3] " Philip Oakley
@ 2022-11-12 14:36           ` Philip Oakley
  2022-11-21  0:34             ` Junio C Hamano
  0 siblings, 1 reply; 22+ messages in thread
From: Philip Oakley @ 2022-11-12 14:36 UTC (permalink / raw)
  To: GitList; +Cc: Self, Junio C Hamano, Taylor Blau, NSENGIYUMVA WILBERFORCE

Instead of replacing with "..", replace with the empty string,
implied by passing NULL, and adjust the padding length calculation.

Extend the existing tests for these pretty formats to include
`Trunc` and Ltrunc` options matching the `trunc` and `ltrunc`
tests.

Signed-off-by: Philip Oakley <philipoakley@iee.email>
---

Removed left over comments from locations that had needed QZ 'space'
conversion in the here-docs.

To: GitList <git@vger.kernel.org>
Cc: Taylor Blau <me@ttaylorr.com>
Cc: Junio C Hamano <gitster@pobox.com>
Cc: NSENGIYUMVA WILBERFORCE <nsengiyumvawilberforce@gmail.com>
In-reply-to: <20221102120853.2013-1-philipoakley@iee.email> 

This should complete the patch (cf. [1] <Y2rPAGp96IwrLS1T@nand.local>)
Note: latest What's Cooking <Y2riRSL+NprJt278@nand.local> hadn't been updated. Tests are included.

A final review would be welcomed.

Range-diff against v3:
1:  498439f0375 ! 1:  d26dabc5271 pretty-formats: add hard truncation, without ellipsis, options
    @@ t/t6006-rev-list-format.sh: commit $head1
      added (hinzugef${added_utf8_part}gt..
      EOF
      
    -+# ZZZ for a space?
     +test_format subject-truncated "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
     +commit $head2
     +changed (ge${changed_utf8_part}ndert) f
    @@ t/t6006-rev-list-format.sh: commit $head1
      added (hinzugef${added_utf8_part_iso88591}gt..
      EOF
      
    -+# need qz qz_to_tab_space
     +test_format complex-subject-Trunc "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
     +commit $head3
     +Test printing of com
    @@ t/t6006-rev-list-format.sh: commit $head1
      added (hinzugef${added_utf8_part}gt..
      EOF
      
    -+# need qz_to_tab_space
     +test_format complex-subject-commitencoding-unset-Trunc "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
     +commit $head3
     +Test printing of com

 Documentation/pretty-formats.txt | 11 +++---
 pretty.c                         | 18 ++++++++-
 t/t4205-log-pretty-formats.sh    | 67 ++++++++++++++++++++++++++++++++
 t/t6006-rev-list-format.sh       | 42 ++++++++++++++++++++
 4 files changed, 132 insertions(+), 6 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 0b4c1c8d98a..0bd339db333 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -146,14 +146,15 @@ The placeholders are:
 '%m':: left (`<`), right (`>`) or boundary (`-`) mark
 '%w([<w>[,<i1>[,<i2>]]])':: switch line wrapping, like the -w option of
 			    linkgit:git-shortlog[1].
-'%<(<N>[,trunc|ltrunc|mtrunc])':: make the next placeholder take at
+'%<(<N>[,trunc|ltrunc|mtrunc|Trunc|Ltrunc])':: make the next placeholder take at
 				  least N columns, padding spaces on
 				  the right if necessary.  Optionally
-				  truncate at the beginning (ltrunc),
-				  the middle (mtrunc) or the end
-				  (trunc) if the output is longer than
-				  N columns.  Note that truncating
+				  truncate (with ellipsis '..') at the beginning (ltrunc) `..ft`,
+				  the middle (mtrunc) `mi..le` or the end
+				  (trunc) `rig..` if the output is longer than
+				  N columns.  Note that truncating with ellipsis
 				  only works correctly with N >= 2.
+				  Use (Trunc|Ltrunc) for hard truncation without ellipsis.
 '%<|(<N>)':: make the next placeholder take at least until Nth
 	     columns, padding spaces on the right if necessary
 '%>(<N>)', '%>|(<N>)':: similar to '%<(<N>)', '%<|(<N>)' respectively,
diff --git a/pretty.c b/pretty.c
index 6cb363ae1c9..1e873d3f41a 100644
--- a/pretty.c
+++ b/pretty.c
@@ -857,7 +857,9 @@ enum trunc_type {
 	trunc_none,
 	trunc_left,
 	trunc_middle,
-	trunc_right
+	trunc_right,
+	trunc_left_hard,
+	trunc_right_hard
 };
 
 struct format_commit_context {
@@ -1145,6 +1147,10 @@ static size_t parse_padding_placeholder(const char *placeholder,
 				c->truncate = trunc_left;
 			else if (starts_with(start, "mtrunc)"))
 				c->truncate = trunc_middle;
+			else if (starts_with(start, "Ltrunc)"))
+				c->truncate = trunc_left_hard;
+			else if (starts_with(start, "Trunc)"))
+				c->truncate = trunc_right_hard;
 			else
 				return 0;
 		} else
@@ -1743,6 +1749,16 @@ static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */
 					    padding - 2, len - (padding - 2),
 					    "..");
 			break;
+		case trunc_left_hard:
+			strbuf_utf8_replace(&local_sb,
+					    0, len - padding,
+					    NULL);
+			break;
+		case trunc_right_hard:
+			strbuf_utf8_replace(&local_sb,
+					    padding, len - padding,
+					    NULL);
+			break;
 		case trunc_none:
 			break;
 		}
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index e448ef2928a..55dca307983 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -261,6 +261,17 @@ test_expect_success 'left alignment formatting with trunc' '
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Trunc' '
+	git log --pretty="tformat:%<(10,Trunc)%s" >actual &&
+	qz_to_tab_space <<-\EOF >expected &&
+	message tw
+	message on
+	add bar  Z
+	initial. a
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'left alignment formatting with trunc. i18n.logOutputEncoding' '
 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,trunc)%s" >actual &&
 	qz_to_tab_space <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
@@ -272,6 +283,17 @@ test_expect_success 'left alignment formatting with trunc. i18n.logOutputEncodin
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Trunc. i18n.logOutputEncoding' '
+	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Trunc)%s" >actual &&
+	qz_to_tab_space <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
+	message tw
+	message on
+	add bar  Z
+	initial. a
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'left alignment formatting with ltrunc' '
 	git log --pretty="tformat:%<(10,ltrunc)%s" >actual &&
 	qz_to_tab_space <<-EOF >expected &&
@@ -283,6 +305,18 @@ test_expect_success 'left alignment formatting with ltrunc' '
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Ltrunc' '
+	git log --pretty="tformat:%<(10,Ltrunc)%s" >actual &&
+	qz_to_tab_space <<-EOF >expected &&
+	essage two
+	essage one
+	add bar  Z
+	an${sample_utf8_part}lich
+	EOF
+	test_cmp expected actual
+'
+
+
 test_expect_success 'left alignment formatting with ltrunc. i18n.logOutputEncoding' '
 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,ltrunc)%s" >actual &&
 	qz_to_tab_space <<-EOF | iconv -f utf-8 -t $test_encoding >expected &&
@@ -294,6 +328,16 @@ test_expect_success 'left alignment formatting with ltrunc. i18n.logOutputEncodi
 	test_cmp expected actual
 '
 
+test_expect_success 'left alignment formatting with Ltrunc. i18n.logOutputEncoding' '
+	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Ltrunc)%s" >actual &&
+	qz_to_tab_space <<-EOF | iconv -f utf-8 -t $test_encoding >expected &&
+	essage two
+	essage one
+	add bar  Z
+	an${sample_utf8_part}lich
+	EOF
+	test_cmp expected actual
+'
 test_expect_success 'left alignment formatting with mtrunc' '
 	git log --pretty="tformat:%<(10,mtrunc)%s" >actual &&
 	qz_to_tab_space <<-\EOF >expected &&
@@ -507,6 +551,19 @@ test_expect_success 'left/right alignment formatting with stealing' '
 	EOF
 	test_cmp expected actual
 '
+
+test_expect_success 'left/right hard alignment formatting with stealing' '
+	git commit --amend -m short --author "long long long <long@me.com>" &&
+	git log --pretty="tformat:%<(10,Trunc)%s%>>(10,Ltrunc)% an" >actual &&
+	cat <<-\EOF >expected &&
+	short long  long long
+	message on   A U Thor
+	add bar      A U Thor
+	initial. a   A U Thor
+	EOF
+	test_cmp expected actual
+'
+
 test_expect_success 'left/right alignment formatting with stealing. i18n.logOutputEncoding' '
 	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,trunc)%s%>>(10,ltrunc)% an" >actual &&
 	cat <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
@@ -517,6 +574,16 @@ test_expect_success 'left/right alignment formatting with stealing. i18n.logOutp
 	EOF
 	test_cmp expected actual
 '
+test_expect_success 'left/right alignment formatting with stealing. i18n.logOutputEncoding' '
+	git -c i18n.logOutputEncoding=$test_encoding log --pretty="tformat:%<(10,Trunc)%s%>>(10,Ltrunc)% an" >actual &&
+	cat <<-\EOF | iconv -f utf-8 -t $test_encoding >expected &&
+	short long  long long
+	message on   A U Thor
+	add bar      A U Thor
+	initial. a   A U Thor
+	EOF
+	test_cmp expected actual
+'
 
 test_expect_success 'strbuf_utf8_replace() not producing NUL' '
 	git log --color --pretty="tformat:%<(10,trunc)%s%>>(10,ltrunc)%C(auto)%d" |
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 41d0ca00b1c..c44935b0ab4 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -218,6 +218,13 @@ commit $head1
 added (hinzugef${added_utf8_part}gt..
 EOF
 
+test_format subject-truncated "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
+commit $head2
+changed (ge${changed_utf8_part}ndert) f
+commit $head1
+added (hinzugef${added_utf8_part}gt)Z
+EOF
+
 test_format body %b <<EOF
 commit $head2
 commit $head1
@@ -400,6 +407,15 @@ commit $head1
 added (hinzugef${added_utf8_part_iso88591}gt..
 EOF
 
+test_format complex-subject-Trunc "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
+commit $head3
+Test printing of com
+commit $head2
+changed (ge${changed_utf8_part_iso88591}ndert) f
+commit $head1
+added (hinzugef${added_utf8_part_iso88591}gt)Z
+EOF
+
 test_format complex-subject-mtrunc "%<($truncate_count,mtrunc)%s" <<EOF
 commit $head3
 Test prin..ex bodies
@@ -418,6 +434,14 @@ commit $head1
 .. (hinzugef${added_utf8_part_iso88591}gt) foo
 EOF
 
+test_format complex-subject-Ltrunc "%<($truncate_count,Ltrunc)%s" <<EOF
+commit $head3
+ng of complex bodies
+commit $head2
+anged (ge${changed_utf8_part_iso88591}ndert) foo
+commit $head1
+ed (hinzugef${added_utf8_part_iso88591}gt) foo
+EOF
 test_expect_success 'setup expected messages (for test %b)' '
 	cat <<-EOF >expected.utf-8 &&
 	commit $head3
@@ -455,6 +479,15 @@ commit $head1
 added (hinzugef${added_utf8_part}gt..
 EOF
 
+test_format complex-subject-commitencoding-unset-Trunc "%<($truncate_count,Trunc)%s" qz_to_tab_space <<EOF
+commit $head3
+Test printing of com
+commit $head2
+changed (ge${changed_utf8_part}ndert) f
+commit $head1
+added (hinzugef${added_utf8_part}gt)Z
+EOF
+
 test_format complex-subject-commitencoding-unset-mtrunc "%<($truncate_count,mtrunc)%s" <<EOF
 commit $head3
 Test prin..ex bodies
@@ -473,6 +506,15 @@ commit $head1
 .. (hinzugef${added_utf8_part}gt) foo
 EOF
 
+test_format complex-subject-commitencoding-unset-Ltrunc "%<($truncate_count,Ltrunc)%s" <<EOF
+commit $head3
+ng of complex bodies
+commit $head2
+anged (ge${changed_utf8_part}ndert) foo
+commit $head1
+ed (hinzugef${added_utf8_part}gt) foo
+EOF
+
 test_format complex-body-commitencoding-unset %b <expected.utf-8
 
 test_expect_success '%x00 shows NUL' '
-- 
2.38.1.windows.1


^ permalink raw reply related	[flat|nested] 22+ messages in thread

* Re: [PATCH v4] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-12 14:36           ` [PATCH v4] " Philip Oakley
@ 2022-11-21  0:34             ` Junio C Hamano
  2022-11-21 18:10               ` Philip Oakley
  0 siblings, 1 reply; 22+ messages in thread
From: Junio C Hamano @ 2022-11-21  0:34 UTC (permalink / raw)
  To: Philip Oakley; +Cc: GitList, Taylor Blau, NSENGIYUMVA WILBERFORCE

Philip Oakley <philipoakley@iee.email> writes:

> Instead of replacing with "..", replace with the empty string,
> implied by passing NULL, and adjust the padding length calculation.

What's the point of saying "implied by passing NULL" here?  Is it an
excuse for passing NULL when passing "" would have sufficed and been
more natural, or something?  Also, it is unclear to whom you are
passing the NULL.  I think that it is sufficient that you said
"replace with the empty string" there.

> Extend the existing tests for these pretty formats to include
> `Trunc` and Ltrunc` options matching the `trunc` and `ltrunc`
> tests.

A more important thing to say is that we add Trunc and Ltrunc, than
we test for these new features ;-)

You may also want to explain why there is no matching Mtrunc added.

I also have another comment on the design.

Imagine there are series of wide characters, each occupying two
display columns, and you give 6 display columns to truncate such a
string into.  "trunc" would give you "[][].." (where [] denotes one
such wide letter that occupies two display columns), and "Trunc"
would give you "[][][]".  Now if you give only 5 display columns,
to fill instead of 6, what should happen?

I do not recall how ".."-stuffed truncation works in this case but
it should notice that it cannot stuff 3 wide letters and give you
"[][].".  The current code may be already buggy, but at least at the
design level, it is fairly clear what the feature _should_ do.

As a design question, what should "Trunc" do in such a case now?  I
do not think we can still call it "hard truncate" if the feature
gives "[][]" (i.e. fill only 4 display columns, resulting in a
string that is not wide enough) or "[][][]" (i.e. exceed 5 columns
that are given), but of course chomping a letter in the middle is
not acceptable behaviour, so ...

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH v4] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-21  0:34             ` Junio C Hamano
@ 2022-11-21 18:10               ` Philip Oakley
  2022-11-22  0:57                 ` Junio C Hamano
  0 siblings, 1 reply; 22+ messages in thread
From: Philip Oakley @ 2022-11-21 18:10 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: GitList, Taylor Blau, NSENGIYUMVA WILBERFORCE

Hi Junio

On 21/11/2022 00:34, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.email> writes:
>
>> Instead of replacing with "..", replace with the empty string,
>> implied by passing NULL, and adjust the padding length calculation.
> What's the point of saying "implied by passing NULL" here?  Is it an
> excuse for passing NULL when passing "" would have sufficed and been
> more natural, or something?  

Passing the empty string was my first approach, however Taylor had
commented "why pass the empty string, when NULL will do", hence I
checked, and yes, we can pass NULL, so I followed that guidance on the
re-roll.

> Also, it is unclear to whom you are
> passing the NULL.  I think that it is sufficient that you said
> "replace with the empty string" there.

I could drop the commit message comment, and keep the NULL being passed
tostrbuf_utf8_replace to indicate the empty string, though that may
create the same reviewer question that Taylor had.
>
>> Extend the existing tests for these pretty formats to include
>> `Trunc` and Ltrunc` options matching the `trunc` and `ltrunc`
>> tests.
> A more important thing to say is that we add Trunc and Ltrunc, than
> we test for these new features ;-)

That would be to swap the paragraphs about, yes?
>
> You may also want to explain why there is no matching Mtrunc added.

Can do, though it felt obvious that the original mtrunc ellipsis would
be necessary for the mid-case.
>
> I also have another comment on the design.
>
> Imagine there are series of wide characters, each occupying two
> display columns, and you give 6 display columns to truncate such a
> string into.  "trunc" would give you "[][].." (where [] denotes one
> such wide letter that occupies two display columns), and "Trunc"
> would give you "[][][]".  Now if you give only 5 display columns,
> to fill instead of 6, what should happen?

My reading of the existing code for ltrunc/mtrunc/trunc was that all
these padding conditions were already covered. It was simply a matter of
column counting.
>
> I do not recall how ".."-stuffed truncation works in this case but
> it should notice that it cannot stuff 3 wide letters and give you
> "[][].".  The current code may be already buggy, but at least at the
> design level, it is fairly clear what the feature _should_ do.
>
> As a design question, what should "Trunc" do in such a case now?  I
> do not think we can still call it "hard truncate" if the feature
> gives "[][]" (i.e. fill only 4 display columns, resulting in a
> string that is not wide enough) or "[][][]" (i.e. exceed 5 columns
> that are given), but of course chomping a letter in the middle is
> not acceptable behaviour, so ...
The design had already covered those cases. The author already had those
thoughts

--

Philip

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH v4] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-21 18:10               ` Philip Oakley
@ 2022-11-22  0:57                 ` Junio C Hamano
  2022-11-23 14:26                   ` Philip Oakley
  0 siblings, 1 reply; 22+ messages in thread
From: Junio C Hamano @ 2022-11-22  0:57 UTC (permalink / raw)
  To: Philip Oakley; +Cc: GitList, Taylor Blau, NSENGIYUMVA WILBERFORCE

Philip Oakley <philipoakley@iee.email> writes:

>> As a design question, what should "Trunc" do in such a case now?  I
>> do not think we can still call it "hard truncate" if the feature
>> gives "[][]" (i.e. fill only 4 display columns, resulting in a
>> string that is not wide enough) or "[][][]" (i.e. exceed 5 columns
>> that are given), but of course chomping a letter in the middle is
>> not acceptable behaviour, so ...
> The design had already covered those cases. The author already had those
> thoughts

Sorry, I was saying that none of

 * giving only [][] to fill only 4 display columns, without filling
   the given 5 display columns,

 * giving [][][] to fill 6 display columns, exceeding the given 5
   display columns,

 * giving [][][ that chomps a letter in the middle, in a failed
   attempt to fill exactly 5 displya columns.

would be a sensible design of the behaviour for "Trunc", so I am not
sure what "had already covered" really mean...


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH v4] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-22  0:57                 ` Junio C Hamano
@ 2022-11-23 14:26                   ` Philip Oakley
  2022-11-25  7:11                     ` Junio C Hamano
  0 siblings, 1 reply; 22+ messages in thread
From: Philip Oakley @ 2022-11-23 14:26 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: GitList, Taylor Blau, NSENGIYUMVA WILBERFORCE

On 22/11/2022 00:57, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.email> writes:
>
>>> As a design question, what should "Trunc" do in such a case now?  I
>>> do not think we can still call it "hard truncate" if the feature
>>> gives "[][]" (i.e. fill only 4 display columns, resulting in a
>>> string that is not wide enough) or "[][][]" (i.e. exceed 5 columns
>>> that are given), but of course chomping a letter in the middle is
>>> not acceptable behaviour, so ...
>> The design had already covered those cases. The author already had those
>> thoughts
> Sorry, I was saying that none of
>
>  * giving only [][] to fill only 4 display columns, without filling
>    the given 5 display columns,
>
>  * giving [][][] to fill 6 display columns, exceeding the given 5
>    display columns,
>
>  * giving [][][ that chomps a letter in the middle, in a failed
>    attempt to fill exactly 5 displya columns.
>
> would be a sensible design of the behaviour for "Trunc", so I am not
> sure what "had already covered" really mean...
>
I'm still unsure what you are trying to say here.

Is this a question about the prior `trunc`, `mtrunc`, and `ltrunc`
design and tests?
e.g. how complete are their tests?

Is it looking for an extended explanation of the 'fit in N-columns'
design approaches that they all have?

I'm happy to add a paragraph saying that an `Mtrunc`, i.e. miss out the
middle characters to fit the set column width, without using the two dot
ellipsis (`..`), was considered a non starter because of potential
confusion when looking at such output when tabulated.

The existing code (and tests) already covers the need to hide the
characters those two dots (ellipsis) consumed win the N-column tabulated
output. The tests also include utf8-encoded characters.

All the previous tests for `trunc` and `'ltrunc` (i.e. with ellipsis)
have been repeated for the `Trunc` and `Ltrunc` (without ellipsis) hard
truncation commands, and their expected outputs updated, including the
use of the qz_to_tab_space  for those case where trailing spaces are now
present.

Does that cover your questions?

--
Philip

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH v4] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-23 14:26                   ` Philip Oakley
@ 2022-11-25  7:11                     ` Junio C Hamano
  2022-11-26 14:32                       ` Philip Oakley
  0 siblings, 1 reply; 22+ messages in thread
From: Junio C Hamano @ 2022-11-25  7:11 UTC (permalink / raw)
  To: Philip Oakley; +Cc: GitList, Taylor Blau, NSENGIYUMVA WILBERFORCE

Philip Oakley <philipoakley@iee.email> writes:

> On 22/11/2022 00:57, Junio C Hamano wrote:
>> Philip Oakley <philipoakley@iee.email> writes:
>>
>>>> As a design question, what should "Trunc" do in such a case now?  I
>>>> do not think we can still call it "hard truncate" if the feature
>>>> gives "[][]" (i.e. fill only 4 display columns, resulting in a
>>>> string that is not wide enough) or "[][][]" (i.e. exceed 5 columns
>>>> that are given), but of course chomping a letter in the middle is
>>>> not acceptable behaviour, so ...
>>> The design had already covered those cases. The author already had those
>>> thoughts
>> Sorry, I was saying that none of
>>
>>  * giving only [][] to fill only 4 display columns, without filling
>>    the given 5 display columns,
>>
>>  * giving [][][] to fill 6 display columns, exceeding the given 5
>>    display columns,
>>
>>  * giving [][][ that chomps a letter in the middle, in a failed
>>    attempt to fill exactly 5 displya columns.
>>
>> would be a sensible design of the behaviour for "Trunc", so I am not
>> sure what "had already covered" really mean...
>>
> I'm still unsure what you are trying to say here.
>
> Is this a question about the prior `trunc`, `mtrunc`, and `ltrunc`
> design and tests?
> e.g. how complete are their tests?

No.  As I said, the existing lowercase ones may already be buggy (I
didn't check), in that they may do "[][].." or "[][][]" when told to
"trunc" fill a string with four or more double-width letters into a
5 display space.  But the point is at least for these with ellipsis
it is fairly clear what the desired behaviour is.  For "trunc" in
the above example, I think the right thing for it to do would be to
do "[][].", i.e. consume exactly 5 display columns, and avoid
exceeding the given space by not giving two dots but just one.

But with "hard truncate", I do not think we can define any sensible
behaviour when we ask it to do the same.  Giving "[][]" leaves one
display space unconsumed and giving "[][][]" would exceed the given
space, so anything you would write after that would be unaligned on
the line.

As to the tests, the question was, whatever the designed behaviour
for the above case, if they record the design choice made by this
series (even though, as I said, I suspect no design choice for the
"hard-fill/trunc odd number of columns with a run of double-width
letters" problem is satisfactory).

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH v4] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-25  7:11                     ` Junio C Hamano
@ 2022-11-26 14:32                       ` Philip Oakley
  2022-11-26 22:44                         ` Philip Oakley
  2022-11-26 23:19                         ` Junio C Hamano
  0 siblings, 2 replies; 22+ messages in thread
From: Philip Oakley @ 2022-11-26 14:32 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: GitList, Taylor Blau, NSENGIYUMVA WILBERFORCE

On 25/11/2022 07:11, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.email> writes:
>
>> On 22/11/2022 00:57, Junio C Hamano wrote:
>>> Philip Oakley <philipoakley@iee.email> writes:
>>>
>>>>> As a design question, what should "Trunc" do in such a case now?  I
>>>>> do not think we can still call it "hard truncate" if the feature
>>>>> gives "[][]" (i.e. fill only 4 display columns, resulting in a
>>>>> string that is not wide enough) or "[][][]" (i.e. exceed 5 columns
>>>>> that are given), but of course chomping a letter in the middle is
>>>>> not acceptable behaviour, so ...
>>>> The design had already covered those cases. The author already had those
>>>> thoughts
>>> Sorry, I was saying that none of
>>>
>>>  * giving only [][] to fill only 4 display columns, without filling
>>>    the given 5 display columns,
>>>
>>>  * giving [][][] to fill 6 display columns, exceeding the given 5
>>>    display columns,
>>>
>>>  * giving [][][ that chomps a letter in the middle, in a failed
>>>    attempt to fill exactly 5 displya columns.
>>>
>>> would be a sensible design of the behaviour for "Trunc", so I am not
>>> sure what "had already covered" really mean...
>>>
>> I'm still unsure what you are trying to say here.
>>
>> Is this a question about the prior `trunc`, `mtrunc`, and `ltrunc`
>> design and tests?
>> e.g. how complete are their tests?
> No.  As I said, the existing lowercase ones may already be buggy (I
> didn't check),

That question hadn't come across in the previous emails.

>  in that they may do "[][].." or "[][][]" when told to
> "trunc" fill a string with four or more double-width letters into a
> 5 display space.  But the point is at least for these with ellipsis
> it is fairly clear what the desired behaviour is.

That "is fairly clear" is probably the problem. In retrospect it's not
clear in the docs that the "%<(N" format is (would appear to be) about
defining the display width, in terminal character columns, that the
selected parameter is to be displayed within.

The code already pads the displayed parameter with spaces as required if
the parameter is shorter than the display width - the else condition in
pretty.c L1750

>   For "trunc" in
> the above example, I think the right thing for it to do would be to
> do "[][].", i.e. consume exactly 5 display columns, and avoid
> exceeding the given space by not giving two dots but just one.

The existing choice is padding "[][]" with a single space to reach 5
display chars.
For the 6-char "[][][]" truncation it is "[][..", i.e. 3 chars from
"[][][]", then the two ".." dots of the ellipsis.
>
> But with "hard truncate", I do not think we can define any sensible
> behaviour 

Given the existing code and the display column expectation, it felt
rather simple to apply the hard cut at the display width, or pad with
spaces if the chars to display were shorter than the allocated columns.

> when we ask it to do the same.  Giving "[][]" leaves one
> display space unconsumed and giving "[][][]" would exceed the given
> space, so anything you would write after that would be unaligned on
> the line.

A careful read (and testing) of the existing 'mtrunc' does show a
rounding error bug though. Its a confusion between the computed start
and end points of the cut that loses one display column (the string
displayed is short by one when the count is odd, IIUC).

>
> As to the tests, the question was, whatever the designed behaviour
> for the above case, if they record the design choice made by this
> series (even though, as I said, I suspect no design choice for the
> "hard-fill/trunc odd number of columns with a run of double-width
> letters" problem is satisfactory).

The existing tests already cover the trailing space padding issues.
However I'd agree that the documentation (and original commit messages
for the existing code) do not make clear the distinction between display
columns to be filled and characters in the displayed parameters (aka
'placeholders').

Within that, there is also the "%<(N" and "%<|(M" lack of clarity, where
the N count is for a single place holder's character count, while the M
value is the terminal's display column number, of the 24x80 column style.

Finally, the docs use of '<N>'  in the middle the place holders title
that also use `<` and `>` is a readability nightmare. Given that the
text then only talks about `N` it may be sensible to drop the
surrounding `<.>` to reduce confusion for these alignment placeholders.

--

Philip

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH v4] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-26 14:32                       ` Philip Oakley
@ 2022-11-26 22:44                         ` Philip Oakley
  2022-11-26 23:19                         ` Junio C Hamano
  1 sibling, 0 replies; 22+ messages in thread
From: Philip Oakley @ 2022-11-26 22:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: GitList, Taylor Blau, NSENGIYUMVA WILBERFORCE

On 26/11/2022 14:32, Philip Oakley wrote:
> A careful read (and testing) of the existing 'mtrunc' does show a
> rounding error bug though. Its a confusion between the computed start
> and end points of the cut that loses one display column (the string
> displayed is short by one when the count is odd, IIUC).

I had confused myself.

My test case `git log --graph --format="%<(19,mtrunc)%d=2" -6` had a
2-char step in the graph that I confused with the effects between
repeated runs with the 'N' value adjusted by +1 and -1.

I then jumped to conclusions about the integer division in the mid
string position of the mtrunc case win the code.

Sorry for that.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH v4] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-26 14:32                       ` Philip Oakley
  2022-11-26 22:44                         ` Philip Oakley
@ 2022-11-26 23:19                         ` Junio C Hamano
  2022-11-28 13:39                           ` Philip Oakley
  1 sibling, 1 reply; 22+ messages in thread
From: Junio C Hamano @ 2022-11-26 23:19 UTC (permalink / raw)
  To: Philip Oakley; +Cc: GitList, Taylor Blau, NSENGIYUMVA WILBERFORCE

Philip Oakley <philipoakley@iee.email> writes:

>>  in that they may do "[][].." or "[][][]" when told to
>> "trunc" fill a string with four or more double-width letters into a
>> 5 display space.  But the point is at least for these with ellipsis
>> it is fairly clear what the desired behaviour is.
>
> That "is fairly clear" is probably the problem. In retrospect it's not
> clear in the docs that the "%<(N" format is (would appear to be) about
> defining the display width, in terminal character columns, that the
> selected parameter is to be displayed within.
>
> The code already pads the displayed parameter with spaces as required if
> the parameter is shorter than the display width - the else condition in
> pretty.c L1750
>
>>   For "trunc" in
>> the above example, I think the right thing for it to do would be to
>> do "[][].", i.e. consume exactly 5 display columns, and avoid
>> exceeding the given space by not giving two dots but just one.
>
> The existing choice is padding "[][]" with a single space to reach 5
> display chars.
> For the 6-char "[][][]" truncation it is "[][..", i.e. 3 chars from
> "[][][]", then the two ".." dots of the ellipsis.

Here, I realize that I did not explain the scenario well.  The
message you are responding to was meant to be a clarification of my
earlier message and it should have done a better job but apparently
I failed.  Sorry, and let me try again.

The single example I meant to use to illustrate the scenario I worry
about is this.  There is a string, in which there are four (or more)
letters, each of which occupies two display columns.  And '[]' in my
earlier messages stood for a SINGLE such letter (I just wanted to
stick to ASCII, instead of using East Asian script, for
illustration).  So "[][.." is not possible (you are chomping the
second such letter in half).

I could use East Asian 一二三四 (there are four letters, denoting
one, two, three, and four, each occupying two display spaces when
typeset in a fixed width font), but to make it easier to see in
ASCII only text, let's pretend "[1]", "[2]", "[3]", "[4]" are such
letters.  You cannot chomp them in the middle (and please pretend
each of them occupy two, not three, display spaces).

When the given display space is 6 columns, we can fit 2 such letters
plus ".." in the space.  If the original string were [1][2][3][4],
it is clear trunk and ltrunk can do "[1][2].." (remember [n] stands
for a single letter whose width is 2 columns, so that takes 6
columns) and "..[3][4]", respectively.  It also is clear that Trunk
and Ltrunk can do "[1][2][3]" and "[2][3][4]", respectively.  We
truncate the given string so that we fill the alloted display
columns fully.

If the given display space is 5 columns, the desirable behaviour for
trunk and ltrunk is still clear.  Instead of consuming two dots, we
could use a single dot as the filler.  As I said, I suspect that the
implementation of trunk and ltrunc does this correctly, though.

My worry is it is not clear what Trunk and Ltrunk should do in that
case.  There is no way to fit a substring of [1][2][3][4] into 5
columns without any filler.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH v4] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-26 23:19                         ` Junio C Hamano
@ 2022-11-28 13:39                           ` Philip Oakley
  2022-11-29  0:18                             ` Junio C Hamano
  0 siblings, 1 reply; 22+ messages in thread
From: Philip Oakley @ 2022-11-28 13:39 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: GitList, Taylor Blau, NSENGIYUMVA WILBERFORCE

On 26/11/2022 23:19, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.email> writes:
>
>>>  in that they may do "[][].." or "[][][]" when told to
>>> "trunc" fill a string with four or more double-width letters into a
>>> 5 display space.  But the point is at least for these with ellipsis
>>> it is fairly clear what the desired behaviour is.
>> That "is fairly clear" is probably the problem. In retrospect it's not
>> clear in the docs that the "%<(N" format is (would appear to be) about
>> defining the display width, in terminal character columns, that the
>> selected parameter is to be displayed within.
>>
>> The code already pads the displayed parameter with spaces as required if
>> the parameter is shorter than the display width - the else condition in
>> pretty.c L1750
>>
>>>   For "trunc" in
>>> the above example, I think the right thing for it to do would be to
>>> do "[][].", i.e. consume exactly 5 display columns, and avoid
>>> exceeding the given space by not giving two dots but just one.
>> The existing choice is padding "[][]" with a single space to reach 5
>> display chars.
>> For the 6-char "[][][]" truncation it is "[][..", i.e. 3 chars from
>> "[][][]", then the two ".." dots of the ellipsis.
> Here, I realize that I did not explain the scenario well.  The
> message you are responding to was meant to be a clarification of my
> earlier message and it should have done a better job but apparently
> I failed.  Sorry, and let me try again.
>
> The single example I meant to use to illustrate the scenario I worry
> about is this.  There is a string, in which there are four (or more)
> letters, each of which occupies two display columns.  And '[]' in my
> earlier messages stood for a SINGLE such letter (I just wanted to
> stick to ASCII, instead of using East Asian script, for
> illustration).  So "[][.." is not possible (you are chomping the
> second such letter in half).
>
> I could use East Asian 一二三四 (there are four letters, denoting
> one, two, three, and four, each occupying two display spaces when
> typeset in a fixed width font),

Thanks for that clarification, I'd been thinking it was about c char
(bytes) such as ASCII and multi-byte characters (code points), e.g.
European umlaut style distinctions.

I hadn't really picked up on the distinction between wide and narrow
'glyphs' (if that's the right term to use).
 
I see that the code does properly count the widths of narrow and wide
code points as 1 and 2 columns of the display, but then doesn't
explicitly try any adjustment for the wide code point problem you noted.
>  but to make it easier to see in
> ASCII only text, let's pretend "[1]", "[2]", "[3]", "[4]" are such
> letters.  You cannot chomp them in the middle (and please pretend
> each of them occupy two, not three, display spaces).
>
> When the given display space is 6 columns, we can fit 2 such letters
> plus ".." in the space.  If the original string were [1][2][3][4],
> it is clear trunk and ltrunk can do "[1][2].." (remember [n] stands
> for a single letter whose width is 2 columns, so that takes 6
> columns) and "..[3][4]", respectively.  It also is clear that Trunk
> and Ltrunk can do "[1][2][3]" and "[2][3][4]", respectively.  We
> truncate the given string so that we fill the alloted display
> columns fully.
>
> If the given display space is 5 columns, the desirable behaviour for
> trunk and ltrunk is still clear.  Instead of consuming two dots, we
> could use a single dot as the filler.  As I said, I suspect that the
> implementation of trunk and ltrunc does this correctly, though.

I believe there is a possible solution that, if we detect a column
over-run, then we can go back and replace the current two column double
dot with a narrow U+2026 Horizontal ellipsis, to regain the needed column.
>
> My worry is it is not clear what Trunk and Ltrunk should do in that
> case.  There is no way to fit a substring of [1][2][3][4] into 5
> columns without any filler.
For this case where the final code point overruns, my solution
could/would be to use the Vertical ellipsis U+22EE "⋮" to re-write that
final character (though the Unicode Replacement Character "�" could be
used, but that's ugly)

I suspect the code would need some close reading to ensure that the
column counting and replacement would correctly cope with the 'off by
one' wide width case inside the strbuf_utf8_replace().

I.e. given the same off-by-one position and replacement length, get back
to the same point to replace either the double dot or the final code
point in an idempotent manner.

The logic feels sound, as long as there are no three wide crocodile
code-points. Either we counted the right number of columns, or we
over-ran by one, so we go back and substitute with a one-for-two
replacement.

Philip

For watchers, https://github.com/microsoft/terminal/issues/4345 shows
some of the issues in the general case.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH v4] pretty-formats: add hard truncation, without ellipsis, options
  2022-11-28 13:39                           ` Philip Oakley
@ 2022-11-29  0:18                             ` Junio C Hamano
  0 siblings, 0 replies; 22+ messages in thread
From: Junio C Hamano @ 2022-11-29  0:18 UTC (permalink / raw)
  To: Philip Oakley; +Cc: GitList, Taylor Blau, NSENGIYUMVA WILBERFORCE

Philip Oakley <philipoakley@iee.email> writes:

>> If the given display space is 5 columns, the desirable behaviour for
>> trunk and ltrunk is still clear.  Instead of consuming two dots, we
>> could use a single dot as the filler.  As I said, I suspect that the
>> implementation of trunk and ltrunc does this correctly, though.
>
> I believe there is a possible solution that, if we detect a column
> over-run, then we can go back and replace the current two column double
> dot with a narrow U+2026 Horizontal ellipsis, to regain the needed column.

It would work, too.  As "trunc" and "ltrunc" (and "mtrunc") are
about "truncate and show the filler to indicate some letters in the
original are not shown, and make the result exactly N columns", it
can use a narrower filler than the originally specified and use the
alloted space.

>> My worry is it is not clear what Trunk and Ltrunk should do in that
>> case.  There is no way to fit a substring of [1][2][3][4] into 5
>> columns without any filler.
> For this case where the final code point overruns, my solution
> could/would be to use the Vertical ellipsis U+22EE "⋮" to re-write that
> final character (though the Unicode Replacement Character "�" could be
> used, but that's ugly)

That would be "trunc" not "Trunc", wouldn't it?  If the capital
letter verions are "hard truncate" without filler, it fundamentally
cannot be done to fill 5 display spaces only with letters each of
which take 2 display spaces.

I am not saying that there is an impossible situation to handle and
"hard truncate" primitives should not be invented.  I just want us
to specify (and document) what happens in such a case, so that it no
longer is an "impossible" situation (we can say "odd/leftover
columns are filled with minimum number of SP to make the result N
display spaces", for example).  And not calling it "hard truncate"
might be a good place to start, as it won't be "hard truncate" with
such a padding.

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2022-11-29  0:18 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-30 18:56 [PATCH 0/1] extend the truncating pretty formats Philip Oakley
2022-10-30 18:56 ` [PATCH 1/1] pretty-formats: add hard truncation, without ellipsis, options Philip Oakley
2022-10-30 19:23   ` Taylor Blau
2022-10-30 22:01     ` Philip Oakley
2022-10-30 23:42       ` Taylor Blau
2022-10-30 21:41 ` [PATCH 0/1] extend the truncating pretty formats Philip Oakley
2022-11-01 22:57 ` [PATCH v2 " Philip Oakley
2022-11-01 22:57   ` [PATCH v2 1/1] pretty-formats: add hard truncation, without ellipsis, options Philip Oakley
2022-11-01 23:05     ` Philip Oakley
2022-11-02  0:45       ` Taylor Blau
2022-11-02 12:08         ` [PATCH v3] " Philip Oakley
2022-11-12 14:36           ` [PATCH v4] " Philip Oakley
2022-11-21  0:34             ` Junio C Hamano
2022-11-21 18:10               ` Philip Oakley
2022-11-22  0:57                 ` Junio C Hamano
2022-11-23 14:26                   ` Philip Oakley
2022-11-25  7:11                     ` Junio C Hamano
2022-11-26 14:32                       ` Philip Oakley
2022-11-26 22:44                         ` Philip Oakley
2022-11-26 23:19                         ` Junio C Hamano
2022-11-28 13:39                           ` Philip Oakley
2022-11-29  0:18                             ` Junio C Hamano

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).