| Message ID | 7b99e5c7c0b0c8d3d7eaaae169e650ebe81964a1.1712486910.git.dsimic@manjaro.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | send-email: make produced outputs more readable | expand |
Dragan Simic <dsimic@manjaro.org> writes: > Emit additional vertical whitespace after the "Send this email [y/n/...]?" > confirmation prompts, more specifically after each confirmed email is sent, > but before the subsequent messages are emitted, to make the produced output > more readable. The subsequent produced messages were bunched together with > the confirmation prompts, as visible in the sample output excerpt below, > which made discerning the outputs unnecessarily harder. > > ... > Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y > OK. Log says: > ... What comes before "send this email" prompt needs to be shown to make the argument more convincing, but with "..." there is no cue to decide if the output is hard to read. > sub send_message { > my ($recipients_ref, $to, $date, $gitversion, $cc, $ccline, $header) = gen_header(); > my @recipients = @$recipients_ref; > + my $prompt_separator = 0; > > my @sendmail_parameters = ('-i', @recipients); > my $raw_from = $sender; > @@ -1556,6 +1557,7 @@ sub send_message { > $confirm = 'never'; > $needs_separator = 1; > } > + $prompt_separator = 1; > } else { > $needs_separator = 1; > } > @@ -1665,6 +1667,7 @@ sub send_message { > $smtp->dataend() or die $smtp->message; > $smtp->code =~ /250|200/ or die sprintf(__("Failed to send %s\n"), $subject).$smtp->message; > } > + print "\n" if ($prompt_separator); "prompt separator" sounds more like a separator that separates prompts, but that is not what is going on, no? Do we even need that new varible in the first place? I am wondering if you can just do the print "\n" right where you assign to that variable. When $confirm is set to 'never', you have both $needs_separtor and $prompt_separator set. Would it mean you'd have two extra blank lines for that message? All these questions you should have been able to avoided with a bit more helpful explanation in the proposed log message, I hope. Thanks. > if ($quiet) { > printf($dry_run ? __("Dry-Sent %s\n") : __("Sent %s\n"), $subject); > } else {
Hello Junio, On 2024-04-08 23:21, Junio C Hamano wrote: > Dragan Simic <dsimic@manjaro.org> writes: > >> Emit additional vertical whitespace after the "Send this email >> [y/n/...]?" >> confirmation prompts, more specifically after each confirmed email is >> sent, >> but before the subsequent messages are emitted, to make the produced >> output >> more readable. The subsequent produced messages were bunched together >> with >> the confirmation prompts, as visible in the sample output excerpt >> below, >> which made discerning the outputs unnecessarily harder. >> >> ... >> Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y >> OK. Log says: >> ... > > What comes before "send this email" prompt needs to be shown to make > the argument more convincing, but with "..." there is no cue to decide > if the output is hard to read. Believe it or not, I also saw the provided sample excerpt as too short. However, when I tried to make it longer and more obvious, it turned out that simply too many lines needed to be included. I'll give it some more though, and possibly delete the sample entirely. >> sub send_message { >> my ($recipients_ref, $to, $date, $gitversion, $cc, $ccline, $header) >> = gen_header(); >> my @recipients = @$recipients_ref; >> + my $prompt_separator = 0; >> >> my @sendmail_parameters = ('-i', @recipients); >> my $raw_from = $sender; >> @@ -1556,6 +1557,7 @@ sub send_message { >> $confirm = 'never'; >> $needs_separator = 1; >> } >> + $prompt_separator = 1; >> } else { >> $needs_separator = 1; >> } >> @@ -1665,6 +1667,7 @@ sub send_message { >> $smtp->dataend() or die $smtp->message; >> $smtp->code =~ /250|200/ or die sprintf(__("Failed to send %s\n"), >> $subject).$smtp->message; >> } >> + print "\n" if ($prompt_separator); > > "prompt separator" sounds more like a separator that separates > prompts, but that is not what is going on, no? Yup, I already wanted to rename that variable, because its name isn't really great, but I didn't do that because it went as such in earlier versions of the patch. Will rename it in the v6. > Do we even need that new varible in the first place? I am wondering > if you can just do the print "\n" right where you assign to that > variable. The reason why the newline isn't emitted right away is because sending the message takes some time, and if we print it right away, there's an additional empty line staring at the user while they wait for the message to be sent. If we emit the newline a bit later, using that variable, it gets displayed together with the printed message, making the displaying of the output much smoother. I already tried to describe that behavior in the patch description. I'll try to improve that description in the v6. > When $confirm is set to 'never', you have both $needs_separtor and > $prompt_separator set. Would it mean you'd have two extra blank > lines for that message? Actually, there are no unneeded blank lines in that case, which I've also tested before sending the patches. One of the blank lines (the one for $needs_separator) goes after the patch messages, and the other one (the one for $prompt_separator) goes after the prompt, which is displayed before the patch messages. > All these questions you should have been able to avoided with a bit > more helpful explanation in the proposed log message, I hope. I already tried to do that, but it seems it needed more detailed explanations in the patch description. Will be improved in the v6. >> if ($quiet) { >> printf($dry_run ? __("Dry-Sent %s\n") : __("Sent %s\n"), $subject); >> } else {
On 2024-04-09 05:25, Dragan Simic wrote: > On 2024-04-08 23:21, Junio C Hamano wrote: >> When $confirm is set to 'never', you have both $needs_separtor and >> $prompt_separator set. Would it mean you'd have two extra blank >> lines for that message? > > Actually, there are no unneeded blank lines in that case, which > I've also tested before sending the patches. One of the blank > lines (the one for $needs_separator) goes after the patch messages, > and the other one (the one for $prompt_separator) goes after the > prompt, which is displayed before the patch messages. Actually, there's a much, _much_ simpler solution for everything, which also works as expected when running "git send-email --quiet" with sendmail.confirm set to "auto" or "never". I need to test it a bit more, and I'll send the updated patches.
On 2024-04-10 05:53, Dragan Simic wrote: > On 2024-04-09 05:25, Dragan Simic wrote: >> On 2024-04-08 23:21, Junio C Hamano wrote: >>> When $confirm is set to 'never', you have both $needs_separtor and >>> $prompt_separator set. Would it mean you'd have two extra blank >>> lines for that message? >> >> Actually, there are no unneeded blank lines in that case, which >> I've also tested before sending the patches. One of the blank >> lines (the one for $needs_separator) goes after the patch messages, >> and the other one (the one for $prompt_separator) goes after the >> prompt, which is displayed before the patch messages. > > Actually, there's a much, _much_ simpler solution for everything, > which also works as expected when running "git send-email --quiet" > with sendmail.confirm set to "auto" or "never". > > I need to test it a bit more, and I'll send the updated patches. This new, simplified approach works well, but I've spotted some more scenarios that also require addition of newlines. Though, based on previous lessons, :) I'll leave that to the follow-up patches.
diff --git a/git-send-email.perl b/git-send-email.perl index 4127fbe6b936..a09bc7fd6b96 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -1510,6 +1510,7 @@ sub gen_header { sub send_message { my ($recipients_ref, $to, $date, $gitversion, $cc, $ccline, $header) = gen_header(); my @recipients = @$recipients_ref; + my $prompt_separator = 0; my @sendmail_parameters = ('-i', @recipients); my $raw_from = $sender; @@ -1556,6 +1557,7 @@ sub send_message { $confirm = 'never'; $needs_separator = 1; } + $prompt_separator = 1; } else { $needs_separator = 1; } @@ -1665,6 +1667,7 @@ sub send_message { $smtp->dataend() or die $smtp->message; $smtp->code =~ /250|200/ or die sprintf(__("Failed to send %s\n"), $subject).$smtp->message; } + print "\n" if ($prompt_separator); if ($quiet) { printf($dry_run ? __("Dry-Sent %s\n") : __("Sent %s\n"), $subject); } else {
Emit additional vertical whitespace after the "Send this email [y/n/...]?" confirmation prompts, more specifically after each confirmed email is sent, but before the subsequent messages are emitted, to make the produced output more readable. The subsequent produced messages were bunched together with the confirmation prompts, as visible in the sample output excerpt below, which made discerning the outputs unnecessarily harder. ... Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y OK. Log says: ... The introduced changes don't emit additional vertical whitespace after the confirmation prompt if the user selects to skip sending the email they were asked about, or if the user selects to quit the procedure entirely. This follows the Git's general approach of not wasting the vertical screen space whenever reasonably possible. The associated test, t9001, requires no updates to cover these changes. Signed-off-by: Dragan Simic <dsimic@manjaro.org> --- git-send-email.perl | 3 +++ 1 file changed, 3 insertions(+)