On 2023-09-25 15:27, torikoshia wrote:
> On Tue, Sep 19, 2023 at 3:23 AM Greg Sabino Mullane
> <htamfids@gmail.com> wrote:
> Thanks for your investigation!
>
>> On Fri, Sep 15, 2023 at 11:11 AM torikoshia
>> <torikoshia@oss.nttdata.com> wrote:
>>> I do not intend to adhere to this rule(my terminals are usually
>>> bigger
>>> than 80 chars per line), but wouldn't it be a not bad direction to
>>> use
>>> 80 characters for all commands?
>>
>> Well, that's the question du jour, isn't it? The 80 character limit is
>> based on punch cards, and really has no place in modern systems. While
>> gnu systems are stuck in the past, many other ones have moved on to
>> more sensible defaults:
>>
>> $ wget --help | wc -L
>> 110
>>
>> $ gcloud --help | wc -L
>> 122
>>
>> $ yum --help | wc -L
>> 122
>>
>> git is an interesting one, as they force things through a pager for
>> their help, but if you look at their raw help text files, they have
>> plenty of times they go past 80 when needed:
>>
>> $ wc -L git/Documentation/git-*.txt | sort -g | tail -20
>> 109 git-filter-branch.txt
>> 109 git-rebase.txt
>> 116 git-diff-index.txt
>> 116 git-http-fetch.txt
>> 117 git-restore.txt
>> 122 git-checkout.txt
>> 122 git-ls-tree.txt
>> 129 git-init-db.txt
>> 131 git-push.txt
>> 132 git-update-ref.txt
>> 142 git-maintenance.txt
>> 144 git-interpret-trailers.txt
>> 146 git-cat-file.txt
>> 148 git-repack.txt
>> 161 git-config.txt
>> 162 git-notes.txt
>> 205 git-stash.txt
>> 251 git-submodule.txt
>>
>> So in summary, I think 80 is a decent soft limit, but let's not stress
>> out about some lines going over that, and make a hard limit of perhaps
>> 120.
>
> +1. It may be a good compromise.
> For enforcing the hard limit, is it better to add a regression test
> like patch 0001?
Ugh, regression tests failed and it appears to be due to reasons related
to meson.
I'm going to investigate it.
--
Regards,
--
Atsushi Torikoshi
NTT DATA Group Corporation