Better visual separation of hunks in `git add -p`

> I'm looking for a way to print some sort of separator between hunks
> when running `git add -p`, as I have a bit of trouble detecting when
> the previous hunk begins and the current one starts. Being able to
> print an empty line or a couple lines filled with "=======" would
> really help me out.

>
> Eugenio Bargiacchi <svalorzen@gmail.com> writes:
>
> > I'm looking for a way to print some sort of separator between hunks
> > when running `git add -p`, as I have a bit of trouble detecting when
> > the previous hunk begins and the current one starts. Being able to
> > print an empty line or a couple lines filled with "=======" would
> > really help me out.
>
> Hmph, my hope when I designed that particular UI was that the
> command prompt for the previous interaction followed by the hunk
> header of the current hunk would give us clear enough separation.
>
> For example, after answering "n" to the prompt for the previous
> hunk, we'd see
>
>     ...
>     +   (merge bff85a338c bl/doc-key-val-sep-fix later to maint).
>     +
>       * Other code cleanup, docfix, build fix, etc.
>         (merge f0e578c69c rs/use-xstrncmpz later to maint).
>         (merge 83e6eb7d7a ba/credential-test-clean-fix later to maint).
>     (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? n
>     @@ -233,3 +245,6 @@ Fixes since v2.44
>         (merge 781fb7b4c2 as/option-names-in-messages later to maint).
>         (merge 51d41dc243 jk/doc-remote-helpers-markup-fix later to maint).
>         (merge e1aaf309db pb/ci-win-artifact-names-fix later to maint).
>     +   (merge ad538c61da jc/index-pack-fsck-levels later to maint).
>     +   (merge 67471bc704 ja/doc-formatting-fix later to maint).
>     ...
>     (2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]?
>
> The '@' (the first character of the hunk header line for the current
> hunk) and "(1/2" are surrounded by lines that begin with a space,
> and the hope was that it was sufficient "separator" already.
>
> These days (long after I stopped mucking with the interactive add
> code actively), the prompt line is painted in prompt_color (you can
> tweak it with the color.interactive.prompt configuration variable,
> it defaults to BOLD BLUE) while the first part of the hunk header
> line is painted in the fraginfo color (default CYAN), which should
> give you even more visual distinction.
>
> Perhaps
>
>     [color "interactive"]
>         prompt = bold red reverse
>
> would be sufficient?  I dunno.
>

> Eugenio Bargiacchi <svalorzen@gmail.com> writes:
> 
>> I'm looking for a way to print some sort of separator between hunks
>> when running `git add -p`, as I have a bit of trouble detecting when
>> the previous hunk begins and the current one starts. Being able to
>> print an empty line or a couple lines filled with "=======" would
>> really help me out.
> 
> Hmph, my hope when I designed that particular UI was that the
> command prompt for the previous interaction followed by the hunk
> header of the current hunk would give us clear enough separation.
> 
> For example, after answering "n" to the prompt for the previous
> hunk, we'd see
> 
>     ...
>     +   (merge bff85a338c bl/doc-key-val-sep-fix later to maint).
>     +
>       * Other code cleanup, docfix, build fix, etc.
>         (merge f0e578c69c rs/use-xstrncmpz later to maint).
>         (merge 83e6eb7d7a ba/credential-test-clean-fix later to maint).
>     (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? n
>     @@ -233,3 +245,6 @@ Fixes since v2.44
>         (merge 781fb7b4c2 as/option-names-in-messages later to maint).
>         (merge 51d41dc243 jk/doc-remote-helpers-markup-fix later to 
> maint).
>         (merge e1aaf309db pb/ci-win-artifact-names-fix later to maint).
>     +   (merge ad538c61da jc/index-pack-fsck-levels later to maint).
>     +   (merge 67471bc704 ja/doc-formatting-fix later to maint).
>     ...
>     (2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]?
> 
> The '@' (the first character of the hunk header line for the current
> hunk) and "(1/2" are surrounded by lines that begin with a space,
> and the hope was that it was sufficient "separator" already.
> 
> These days (long after I stopped mucking with the interactive add
> code actively), the prompt line is painted in prompt_color (you can
> tweak it with the color.interactive.prompt configuration variable,
> it defaults to BOLD BLUE) while the first part of the hunk header
> line is painted in the fraginfo color (default CYAN), which should
> give you even more visual distinction.
> 
> Perhaps
> 
>     [color "interactive"]
> 	prompt = bold red reverse
> 
> would be sufficient?  I dunno.

> Here's a possible solution, or better said a new configuration option,
> which I've been thinking about for a while...  When running "add -p",
> displayed chunks can sometimes become confusing or a bit hard on the
> eyes, but simply clearing the screen _before_ displaying any new step
> (i.e. a new chunk, interactive help, etc.) could make it much easier
> on the eyes.  It would be a new option, of course.

> Dragan Simic <dsimic@manjaro.org> writes:
> 
>> Here's a possible solution, or better said a new configuration option,
>> which I've been thinking about for a while...  When running "add -p",
>> displayed chunks can sometimes become confusing or a bit hard on the
>> eyes, but simply clearing the screen _before_ displaying any new step
>> (i.e. a new chunk, interactive help, etc.) could make it much easier
>> on the eyes.  It would be a new option, of course.
> 
> Or your 'p' option can have a 'P' variant that clears before prints.
> I have this feeling that even those who want clearing of the screen,
> they do not want it always on, when many of their hunks are 7 lines
> long.

> Here's a possible solution, or better said a new configuration option,
> which I've been thinking about for a while...  When running "add -p",
> displayed chunks can sometimes become confusing or a bit hard on the
> eyes, but simply clearing the screen _before_ displaying any new step
> (i.e. a new chunk, interactive help, etc.) could make it much easier
> on the eyes.  It would be a new option, of course.

>
> On 2024-03-28 19:21, Junio C Hamano wrote:
> > Dragan Simic <dsimic@manjaro.org> writes:
> >
> >> Here's a possible solution, or better said a new configuration option,
> >> which I've been thinking about for a while...  When running "add -p",
> >> displayed chunks can sometimes become confusing or a bit hard on the
> >> eyes, but simply clearing the screen _before_ displaying any new step
> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
> >> on the eyes.  It would be a new option, of course.
> >
> > Or your 'p' option can have a 'P' variant that clears before prints.
> > I have this feeling that even those who want clearing of the screen,
> > they do not want it always on, when many of their hunks are 7 lines
> > long.
>
> That would be even better.  Though, would adding new short command-line
> option to git-add be frowned upon?

>> Here's a possible solution, or better said a new configuration option,
>> which I've been thinking about for a while...  When running "add -p",
>> displayed chunks can sometimes become confusing or a bit hard on the
>> eyes, but simply clearing the screen _before_ displaying any new step
>> (i.e. a new chunk, interactive help, etc.) could make it much easier
>> on the eyes.  It would be a new option, of course.
> 
> In my head, an option to print an arbitrary string would be amazing,
> since then if wanted one can print a special character that clears the
> screen, or simply add some space, or something else.

> On Thu, 28 Mar 2024 at 19:29, Dragan Simic <dsimic@manjaro.org> wrote:
>> 
>> On 2024-03-28 19:21, Junio C Hamano wrote:
>> > Dragan Simic <dsimic@manjaro.org> writes:
>> >
>> >> Here's a possible solution, or better said a new configuration option,
>> >> which I've been thinking about for a while...  When running "add -p",
>> >> displayed chunks can sometimes become confusing or a bit hard on the
>> >> eyes, but simply clearing the screen _before_ displaying any new step
>> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
>> >> on the eyes.  It would be a new option, of course.
>> >
>> > Or your 'p' option can have a 'P' variant that clears before prints.
>> > I have this feeling that even those who want clearing of the screen,
>> > they do not want it always on, when many of their hunks are 7 lines
>> > long.
>> 
>> That would be even better.  Though, would adding new short 
>> command-line
>> option to git-add be frowned upon?

>
> On 2024-03-28 20:01, Eugenio Bargiacchi wrote:
> >> Here's a possible solution, or better said a new configuration option,
> >> which I've been thinking about for a while...  When running "add -p",
> >> displayed chunks can sometimes become confusing or a bit hard on the
> >> eyes, but simply clearing the screen _before_ displaying any new step
> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
> >> on the eyes.  It would be a new option, of course.
> >
> > In my head, an option to print an arbitrary string would be amazing,
> > since then if wanted one can print a special character that clears the
> > screen, or simply add some space, or something else.
>
> Huh, letting the users handle screen clearing that way could be rather
> problematic, because different terminals may do it differently.
>
> > On Thu, 28 Mar 2024 at 19:29, Dragan Simic <dsimic@manjaro.org> wrote:
> >>
> >> On 2024-03-28 19:21, Junio C Hamano wrote:
> >> > Dragan Simic <dsimic@manjaro.org> writes:
> >> >
> >> >> Here's a possible solution, or better said a new configuration option,
> >> >> which I've been thinking about for a while...  When running "add -p",
> >> >> displayed chunks can sometimes become confusing or a bit hard on the
> >> >> eyes, but simply clearing the screen _before_ displaying any new step
> >> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
> >> >> on the eyes.  It would be a new option, of course.
> >> >
> >> > Or your 'p' option can have a 'P' variant that clears before prints.
> >> > I have this feeling that even those who want clearing of the screen,
> >> > they do not want it always on, when many of their hunks are 7 lines
> >> > long.
> >>
> >> That would be even better.  Though, would adding new short
> >> command-line
> >> option to git-add be frowned upon?

> But then each can configure it specifically for their terminal, no? Or
> are you afraid that a user may use different terminals at the same
> time, so the same config would be applied, so it would not work? In
> any case, my suggestion was aiming mainly to avoid having to add
> multiple options while allowing to freely customize the separators,
> but if that will not work in general to clear, that makes sense as
> well.

> On Thu, 28 Mar 2024 at 20:04, Dragan Simic <dsimic@manjaro.org> wrote:
>> 
>> On 2024-03-28 20:01, Eugenio Bargiacchi wrote:
>> >> Here's a possible solution, or better said a new configuration option,
>> >> which I've been thinking about for a while...  When running "add -p",
>> >> displayed chunks can sometimes become confusing or a bit hard on the
>> >> eyes, but simply clearing the screen _before_ displaying any new step
>> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
>> >> on the eyes.  It would be a new option, of course.
>> >
>> > In my head, an option to print an arbitrary string would be amazing,
>> > since then if wanted one can print a special character that clears the
>> > screen, or simply add some space, or something else.
>> 
>> Huh, letting the users handle screen clearing that way could be rather
>> problematic, because different terminals may do it differently.
>> 
>> > On Thu, 28 Mar 2024 at 19:29, Dragan Simic <dsimic@manjaro.org> wrote:
>> >>
>> >> On 2024-03-28 19:21, Junio C Hamano wrote:
>> >> > Dragan Simic <dsimic@manjaro.org> writes:
>> >> >
>> >> >> Here's a possible solution, or better said a new configuration option,
>> >> >> which I've been thinking about for a while...  When running "add -p",
>> >> >> displayed chunks can sometimes become confusing or a bit hard on the
>> >> >> eyes, but simply clearing the screen _before_ displaying any new step
>> >> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
>> >> >> on the eyes.  It would be a new option, of course.
>> >> >
>> >> > Or your 'p' option can have a 'P' variant that clears before prints.
>> >> > I have this feeling that even those who want clearing of the screen,
>> >> > they do not want it always on, when many of their hunks are 7 lines
>> >> > long.
>> >>
>> >> That would be even better.  Though, would adding new short
>> >> command-line
>> >> option to git-add be frowned upon?

> Dragan Simic <dsimic@manjaro.org> writes:
> 
>> Of course, users could pick the right escape sequences for their
>> terminals, but as you already noted, the same configurations could
>> end up being used on different terminals.  For example, even SSHing
>> into a machine using a different SSH client could lead to a mess.
> 
> There is a separate discussion of conditional configuration based on
> environment variable settings, e.g.
> 
>     [includeIf "env:TERM:vt100"]
> 	path = ~/.git-config-bits/vt100
> 
> where the named file might have
> 
>     [prompt] prefix = "\033[H\033[J"
> 
> so it is certainly doable.
> 
> It is a different story if doing so is sensible, of course.

>
> On 2024-03-28 21:43, Junio C Hamano wrote:
> > Dragan Simic <dsimic@manjaro.org> writes:
> >
> >> Of course, users could pick the right escape sequences for their
> >> terminals, but as you already noted, the same configurations could
> >> end up being used on different terminals.  For example, even SSHing
> >> into a machine using a different SSH client could lead to a mess.
> >
> > There is a separate discussion of conditional configuration based on
> > environment variable settings, e.g.
> >
> >     [includeIf "env:TERM:vt100"]
> >       path = ~/.git-config-bits/vt100
> >
> > where the named file might have
> >
> >     [prompt] prefix = "\033[H\033[J"
> >
> > so it is certainly doable.
> >
> > It is a different story if doing so is sensible, of course.
>
> Quite frankly, I think that would be like opening a can of worms.
> In other words, if we end up implementing support for the "add -P"
> prefix, allowing the users to do whatever they want with the prefixes
> would surely be fine, but only if we implement "add -P" at the same
> time, to already provide a reliable and simple way for clearing the
> screen.

> It seems to me that the two options are orthogonal: allowing the user
> to add an arbitrary prefix is not a block for allowing the user to
> clear the screen or vice-versa. If anything, the arbitrary prefix
> seems the more general flag to me as it at least offers a way (however
> unportable) to perform a clear. So saying that if we do not allow the
> user to clear the screen then it is not fine to add arbitrary prefixes
> seems strange.

> On Thu, 28 Mar 2024 at 22:19, Dragan Simic <dsimic@manjaro.org> wrote:
>> 
>> On 2024-03-28 21:43, Junio C Hamano wrote:
>> > Dragan Simic <dsimic@manjaro.org> writes:
>> >
>> >> Of course, users could pick the right escape sequences for their
>> >> terminals, but as you already noted, the same configurations could
>> >> end up being used on different terminals.  For example, even SSHing
>> >> into a machine using a different SSH client could lead to a mess.
>> >
>> > There is a separate discussion of conditional configuration based on
>> > environment variable settings, e.g.
>> >
>> >     [includeIf "env:TERM:vt100"]
>> >       path = ~/.git-config-bits/vt100
>> >
>> > where the named file might have
>> >
>> >     [prompt] prefix = "\033[H\033[J"
>> >
>> > so it is certainly doable.
>> >
>> > It is a different story if doing so is sensible, of course.
>> 
>> Quite frankly, I think that would be like opening a can of worms.
>> In other words, if we end up implementing support for the "add -P"
>> prefix, allowing the users to do whatever they want with the prefixes
>> would surely be fine, but only if we implement "add -P" at the same
>> time, to already provide a reliable and simple way for clearing the
>> screen.