From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 509F920248 for ; Mon, 1 Apr 2019 11:52:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726843AbfDALw3 (ORCPT ); Mon, 1 Apr 2019 07:52:29 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:43115 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725882AbfDALw2 (ORCPT ); Mon, 1 Apr 2019 07:52:28 -0400 Received: by mail-wr1-f67.google.com with SMTP id k17so11594802wrx.10 for ; Mon, 01 Apr 2019 04:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Pgw0q6Wuvjq06+I2emdoNnWxe7ebvcI62LtKRQ0d+R0=; b=guPyy8MpNsrpVFws++3Gu/Yda1j/qMcDe+jpm7Nexo+7gMlIffmDNu3mprO3vSmh12 BSrH3ZxebKbG6kz62avzUI0KmDPk8Nfg2MqbBBREjg5+SZtcHejHEZYEdxLIL1MHu7Ij z95mS3VfVwafXe46pRorA8EC7rQ+5YuBPSD/62R9dnePdqj569ki4ji1expOnXdyinIZ 98DrUrXWmtiXz8C4VtwqmXeJ7Gylbah7Pq/UHiDSQCpbyErzxryNOzoROiONl5sCRmYk 3p34MIIgQmzFBPCqEPRBWhPNoaCCghcNkSaO2BDGOdv0cYY97m8SaBEageCoiM62BhX6 PR5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Pgw0q6Wuvjq06+I2emdoNnWxe7ebvcI62LtKRQ0d+R0=; b=KghydP6Rbgziw+FrZ8sw3q1Fwv9XICrp5Lm2ZBvHXj/avVGcN86GHCaBU6SijMOM+N PR+TSR3iA0g2Z33RDVDFXHDFfeFsfSfMfrb3OFfCwUJ2Xa363PlAW3HYiuUnGlh69lxs pRTr6o6aj02Red8PhkE0e+DcKYEp/wOUbHrfS0C0WbOfUQ3xlHNMSrEWFoAbgfyrjQkt MvixmKU+b+TsL0RPqRie6krEl4bMn6tCEaHHPvEnCPuJkZUgTIWiULCahx34zXXaWeL3 rZbif327x4+h3Fu4YpbbcDZCbiH7DmX+t28ymrUm8p8gopEc3v8oneNJvsxBkuVLQ7sI AE3w== X-Gm-Message-State: APjAAAUZlXeYTk6ShjuW8hDQ8RnlNUcQQTjcm33skyhOhgVKWSDGu13A GJylV1zqzg2NsFh2feAabdQ= X-Google-Smtp-Source: APXvYqxytAn3zAN5A0+NXK2en0ea9QPGh5Halx8WLQsTvEkZfJYE291+MmovcC7X5Kbuun6W2Rs01w== X-Received: by 2002:a5d:6b04:: with SMTP id v4mr2337637wrw.69.1554119546556; Mon, 01 Apr 2019 04:52:26 -0700 (PDT) Received: from localhost.localdomain (x4db6660d.dyn.telefonica.de. [77.182.102.13]) by smtp.gmail.com with ESMTPSA id f11sm11250970wrm.30.2019.04.01.04.52.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 01 Apr 2019 04:52:25 -0700 (PDT) From: =?UTF-8?q?SZEDER=20G=C3=A1bor?= To: Junio C Hamano Cc: =?UTF-8?q?=C3=86var=20Arnfj=C3=B6r=C3=B0=20Bjarmason?= , Jeff King , Duy Nguyen , Luke Mewburn , git@vger.kernel.org, =?UTF-8?q?SZEDER=20G=C3=A1bor?= Subject: [PATCH v2 4/4] progress: break too long progress bar lines Date: Mon, 1 Apr 2019 13:52:17 +0200 Message-Id: <20190401115217.3423-5-szeder.dev@gmail.com> X-Mailer: git-send-email 2.21.0.539.g07239c3a71.dirty In-Reply-To: <20190401115217.3423-1-szeder.dev@gmail.com> References: <20190325103844.26749-1-szeder.dev@gmail.com> <20190401115217.3423-1-szeder.dev@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Some of the recently added progress indicators have quite long titles, which might be even longer when translated to some languages, and when they are shown while operating on bigger repositories, then the progress bar grows longer than the default 80 column terminal width. When the progress bar exceeds the width of the terminal it gets line-wrapped, and after that the CR at the end doesn't return to the beginning of the progress bar, but to the first column of its last line. Consequently, the first line of the previously shown progress bar is not overwritten by the next, and we end up with a bunch of truncated progress bar lines scrolling past: $ LANG=es_ES.UTF-8 git commit-graph write Encontrando commits para commit graph entre los objetos empaquetados: 2% (1599 Encontrando commits para commit graph entre los objetos empaquetados: 3% (1975 Encontrando commits para commit graph entre los objetos empaquetados: 4% (2633 Encontrando commits para commit graph entre los objetos empaquetados: 5% (3292 [...] Prevent this by breaking progress bars after the title once they exceed the width of the terminal, so the counter and optional percentage and throughput, i.e. all changing parts, are on the last line. Subsequent updates will from then on only refresh the changing parts, but not the title, and it will look like this: $ LANG=es_ES.UTF-8 ~/src/git/git commit-graph write Encontrando commits para commit graph entre los objetos empaquetados: 100% (6584502/6584502), listo. Calculando números de generación de commit graph: 100% (824705/824705), listo. Escribiendo commit graph en 4 pasos: 100% (3298820/3298820), listo. Note that the number of columns in the terminal is cached by term_columns(), so this might not kick in when it should when a terminal window is resized while the operation is running. Furthermore, this change won't help if the terminal is so narrow that the counters don't fit on one line, but I would put this in the "If it hurts, don't do it" box. Signed-off-by: SZEDER Gábor --- progress.c | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/progress.c b/progress.c index 3149ecd460..e28ccdafd2 100644 --- a/progress.c +++ b/progress.c @@ -8,11 +8,12 @@ * published by the Free Software Foundation. */ -#include "git-compat-util.h" +#include "cache.h" #include "gettext.h" #include "progress.h" #include "strbuf.h" #include "trace.h" +#include "utf8.h" #define TP_IDX_MAX 8 @@ -37,6 +38,8 @@ struct progress { struct throughput *throughput; uint64_t start_ns; struct strbuf counters_sb; + int title_len; + int split; }; static volatile sig_atomic_t progress_update; @@ -114,8 +117,24 @@ static void display(struct progress *progress, uint64_t n, const char *done) const char *eol = done ? done : "\r"; int clear_len = counters_sb->len < last_count_len ? last_count_len - counters_sb->len : 0; - fprintf(stderr, "%s: %s%-*s", progress->title, - counters_sb->buf, clear_len, eol); + int progress_line_len = progress->title_len + + counters_sb->len + 2; + int cols = term_columns(); + + if (progress->split) { + fprintf(stderr, " %s%-*s", counters_sb->buf, + clear_len, eol); + } else if (!done && cols < progress_line_len) { + clear_len = progress->title_len + 1 < cols ? + cols - progress->title_len - 1 : 0; + fprintf(stderr, "%s:%*s\n %s%s", + progress->title, clear_len, "", + counters_sb->buf, eol); + progress->split = 1; + } else { + fprintf(stderr, "%s: %s%-*s", progress->title, + counters_sb->buf, clear_len, eol); + } fflush(stderr); } progress_update = 0; @@ -221,6 +240,8 @@ static struct progress *start_progress_delay(const char *title, uint64_t total, progress->throughput = NULL; progress->start_ns = getnanotime(); strbuf_init(&progress->counters_sb, 0); + progress->title_len = utf8_strwidth(title); + progress->split = 0; set_progress_signal(); return progress; } -- 2.21.0.539.g07239c3a71.dirty