All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: "Rubén Justo" <rjusto@gmail.com>, "Git List" <git@vger.kernel.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2 2/2] add-patch: do not print hunks repeatedly
Date: Tue, 26 Mar 2024 14:39:18 +0000	[thread overview]
Message-ID: <b3c6a5dd-2d78-4149-95f4-57cf8bd1240a@gmail.com> (raw)
In-Reply-To: <c123bf09-7f4c-46f5-aa09-48b2816bf85d@gmail.com>

Hi Rubén

On 26/03/2024 00:17, Rubén Justo wrote:
>      $ git add -p
>      diff --git a/add-patch.c b/add-patch.c
>      index 52be1ddb15..8fb75e82e2 100644
>      --- a/add-patch.c
>      +++ b/add-patch.c
>      @@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
>       static int patch_update_file(struct add_p_state *s,
>       			     struct file_diff *file_diff)
>       {
>      -	size_t hunk_index = 0;
>      +	size_t hunk_index = 0, prev_hunk_index = -1;
>       	ssize_t i, undecided_previous, undecided_next;
>       	struct hunk *hunk;
>       	char ch;
>      (1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? U
>      y - stage this hunk
>      n - do not stage this hunk
>      q - quit; do not stage this hunk or any of the remaining ones
>      a - stage this hunk and all later hunks in the file
>      d - do not stage this hunk or any of the later hunks in the file
>      j - leave this hunk undecided, see next undecided hunk
>      J - leave this hunk undecided, see next hunk
>      g - select a hunk to go to
>      / - search for a hunk matching the given regex
>      e - manually edit the current hunk
>      p - print again the current hunk
>      ? - print help
>      @@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
>       static int patch_update_file(struct add_p_state *s,
>       			     struct file_diff *file_diff)
>       {
>      -	size_t hunk_index = 0;
>      +	size_t hunk_index = 0, prev_hunk_index = -1;
>       	ssize_t i, undecided_previous, undecided_next;
>       	struct hunk *hunk;
>       	char ch;
>      (1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
> 
> Printing the chunk again followed by the question can be confusing as
> the user has to pay special attention to notice that the same chunk is
> being reconsidered.

As we print a long help message if we don't re-display the hunk it ends 
up being separated from the prompt. Personally I find the help message 
quite annoying when I've fat-fingered the wrong key - I'd prefer a 
shorter message pointing to "?" to display more help. We already do 
something similar if the user presses a key such as "s" that is disabled 
for the current hunk.

> It can also be problematic if the chunk is longer than one screen height
> because the result of the previous iteration is lost off the screen (the
> help guide in the previous example).
> 
> To avoid such problems, stop printing the chunk if the iteration does
> not advance to a different chunk.
> 
> Signed-off-by: Rubén Justo <rjusto@gmail.com>
> ---
>   add-patch.c | 18 ++++++++++++------
>   1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/add-patch.c b/add-patch.c
> index 444fd75b2a..54a7d9c01f 100644
> --- a/add-patch.c
> +++ b/add-patch.c
> @@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
>   static int patch_update_file(struct add_p_state *s,
>   			     struct file_diff *file_diff)
>   {
> -	size_t hunk_index = 0;
> +	size_t hunk_index = 0, prev_hunk_index = -1;

I found the name a bit confusing as we have keys for displaying the 
previous hunk and it make me think of that. As it is used to record the 
index of the hunk that we've rendered perhaps "rendered_hunk_index" 
would be a better name. Also as it needs to hold a negative value we 
should declare it as ssize_t like the variables on the line below.

>   	ssize_t i, undecided_previous, undecided_next;
>   	struct hunk *hunk;
>   	char ch;
> @@ -1448,10 +1448,14 @@ static int patch_update_file(struct add_p_state *s,
>   
>   		strbuf_reset(&s->buf);
>   		if (file_diff->hunk_nr) {
> -			render_hunk(s, hunk, 0, colored, &s->buf);
> -			fputs(s->buf.buf, stdout);
> +			if (prev_hunk_index != hunk_index) {
> +				render_hunk(s, hunk, 0, colored, &s->buf);
> +				fputs(s->buf.buf, stdout);
> +				strbuf_reset(&s->buf);
> +
> +				prev_hunk_index = hunk_index;
> +			}
>   
> -			strbuf_reset(&s->buf);

I'd be inclined to leave this line as is to make it clear that the 
strbuf is always cleared before adding the keybindings.

>   			if (undecided_previous >= 0) {
>   				permitted |= ALLOW_GOTO_PREVIOUS_UNDECIDED_HUNK;
>   				strbuf_addstr(&s->buf, ",k");
> @@ -1649,10 +1653,12 @@ static int patch_update_file(struct add_p_state *s,
>   			if (!(permitted & ALLOW_SPLIT))

style: as you're adding braces to the other clause in this if statement 
you should add them to this clause as well.

Best Wishes

Phillip

  reply	other threads:[~2024-03-26 14:39 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-25 20:59 [PATCH 0/2] improve interactive-patch Rubén Justo
2024-03-25 21:05 ` [PATCH 1/2] add-patch: introduce 'p' in interactive-patch Rubén Justo
2024-03-25 21:38   ` Junio C Hamano
2024-03-25 23:15     ` Rubén Justo
2024-03-25 23:42       ` Junio C Hamano
2024-03-25 21:07 ` [PATCH 2/2] add-patch: do not print hunks repeatedly Rubén Justo
2024-03-25 21:34   ` Junio C Hamano
2024-03-26  0:15 ` [PATCH v2 0/2] improve interactive-patch Rubén Justo
2024-03-26  0:17   ` [PATCH v2 1/2] add-patch: introduce 'p' in interactive-patch Rubén Justo
2024-03-26 14:38     ` Phillip Wood
2024-03-26 18:40       ` Rubén Justo
2024-03-27 10:55         ` Phillip Wood
2024-03-26  0:17   ` [PATCH v2 2/2] add-patch: do not print hunks repeatedly Rubén Justo
2024-03-26 14:39     ` Phillip Wood [this message]
2024-03-26 18:46       ` Rubén Justo
2024-03-27 11:06         ` Phillip Wood
2024-03-28  0:39           ` Rubén Justo
2024-03-26 14:37   ` [PATCH v2 0/2] improve interactive-patch Phillip Wood
2024-03-26 15:31     ` Junio C Hamano
2024-03-26 18:48       ` Rubén Justo
2024-03-26 19:13         ` Junio C Hamano
2024-03-26 20:26           ` Rubén Justo
2024-03-29 19:26           ` Rubén Justo
2024-03-29 19:48             ` Dragan Simic
2024-03-30 13:49               ` Rubén Justo
2024-03-30 17:06             ` Junio C Hamano
2024-03-27 11:14       ` Phillip Wood
2024-03-27 15:43         ` Junio C Hamano
2024-03-27 16:14           ` Phillip Wood
2024-03-28  1:03           ` Rubén Justo
2024-03-26 18:46     ` Rubén Justo
2024-03-28  1:10   ` [PATCH v3 " Rubén Justo
2024-03-28  1:12     ` [PATCH v3 1/2] add-patch: introduce 'p' in interactive-patch Rubén Justo
2024-03-28 14:45       ` Junio C Hamano
2024-03-28  1:12     ` [PATCH v3 2/2] add-patch: do not print hunks repeatedly Rubén Justo
2024-03-28 14:46       ` Junio C Hamano
2024-03-29  3:49         ` Rubén Justo
2024-03-29  3:56     ` [PATCH v4 0/2] improve interactive-patch Rubén Justo
2024-03-29  3:58       ` [PATCH v4 1/2] add-patch: introduce 'p' in interactive-patch Rubén Justo
2024-03-29  3:58       ` [PATCH v4 2/2] add-patch: do not print hunks repeatedly Rubén Justo
2024-03-29 10:41         ` phillip.wood123
2024-03-29 11:37           ` Rubén Justo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=b3c6a5dd-2d78-4149-95f4-57cf8bd1240a@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=rjusto@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.