git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Beller <sbeller@google.com>
To: git@vger.kernel.org
Cc: gitster@pobox.com, Stefan Beller <sbeller@google.com>
Subject: [PATCH] usage_with_options: omit double new line on empty option list
Date: Fri, 25 Aug 2017 12:28:13 -0700	[thread overview]
Message-ID: <20170825192813.15697-1-sbeller@google.com> (raw)
In-Reply-To: <xmqqy3q7sge2.fsf@gitster.mtv.corp.google.com/>

Currently the worktree command gives its usage, when no subcommand is
given. However there are no general options, all options are related to
the subcommands itself, such that:

 #    $ git worktree
 #    usage: git worktree add [<options>] <path> [<branch>]
 #       or: git worktree list [<options>]
 #       or: git worktree lock [<options>] <path>
 #       or: git worktree prune [<options>]
 #       or: git worktree unlock <path>
 #
 #
 #    $

Note the two empty lines at the end of the usage string. This is because
the toplevel usage is printed with an empty options list.

Only print a new line after the option list if it is not empty.

Signed-off-by: Stefan Beller <sbeller@google.com>
---

> I have this feeling that this patch may not be sufficient.
>
> The reason for the first blank line is because we unconditionally
> emit one, expecting that we would have a list of options to show and
> want to separate the usage from that list, and the fix in this patch
> is correct---it is the right way to suppress it.
>
> But why do we need the second blank line in this case?  There is a
> similar unconditional LF near the end of this function.  Is somebody
> else (other than usage_with_options() which will exit immeidately)
> calls this function and expects to say something more after what
> this function said, and is this extra blank line at the end is to
> prepare for that caller?

Good point, parse_options[_step] also makes use of the 
usage_with_options_internal, such that the regular options
need to work, with a potentially interesting arrangement of OPTION_GROUPs.

I think this one is cleaner, as it omits the correct LF.

Thanks,
Stefan

 parse-options.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/parse-options.c b/parse-options.c
index 0dd9fc6a0d..2829c16b01 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -580,6 +580,7 @@ static int usage_with_options_internal(struct parse_opt_ctx_t *ctx,
 				       const char * const *usagestr,
 				       const struct option *opts, int full, int err)
 {
+	int new_line_after_opts;
 	FILE *outfile = err ? stderr : stdout;
 
 	if (!usagestr)
@@ -606,6 +607,8 @@ static int usage_with_options_internal(struct parse_opt_ctx_t *ctx,
 	if (opts->type != OPTION_GROUP)
 		fputc('\n', outfile);
 
+	new_line_after_opts = (opts->type != OPTION_END);
+
 	for (; opts->type != OPTION_END; opts++) {
 		size_t pos;
 		int pad;
@@ -645,7 +648,9 @@ static int usage_with_options_internal(struct parse_opt_ctx_t *ctx,
 		}
 		fprintf(outfile, "%*s%s\n", pad + USAGE_GAP, "", _(opts->help));
 	}
-	fputc('\n', outfile);
+
+	if (new_line_after_opts)
+		fputc('\n', outfile);
 
 	if (!err && ctx && ctx->flags & PARSE_OPT_SHELL_EVAL)
 		fputs("EOF\n", outfile);
-- 
2.14.0.rc0.3.g6c2e499285


       reply	other threads:[~2017-08-25 19:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <xmqqy3q7sge2.fsf@gitster.mtv.corp.google.com/>
2017-08-25 19:28 ` Stefan Beller [this message]
2017-08-25 20:27   ` [PATCH] usage_with_options: omit double new line on empty option list Junio C Hamano
2017-08-25 21:06     ` Stefan Beller
2017-08-25 21:17       ` Junio C Hamano
2017-08-25 16:48 Stefan Beller
2017-08-25 17:18 ` Junio C Hamano
2017-08-25 17:19   ` Stefan Beller
2017-08-25 17:21   ` Junio C Hamano
2017-08-25 17:31 ` Junio C Hamano

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=20170825192813.15697-1-sbeller@google.com \
    --to=sbeller@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 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 NNTP newsgroup(s).