[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nano-devel] [PATCH 3/3] docs: an attempt at updating the documentat
Re: [Nano-devel] [PATCH 3/3] docs: an attempt at updating the documentation for the changed defaults
Mon, 21 Jan 2019 09:51:55 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
Op 17-01-19 om 21:00 schreef David Ramsey:
> Benno Schulenberg:
>> The --nowrap option doesn't need a counterpart because it already has
>> one: --fill=<number>. (Although that options is really two things in
>> one: it sets the fill width for justifying, and switches on automatic
> I've found that double functionality more and more annoying lately. I prefer
> to keep hard line wrapping off and justify everything afterwards (and if
> wrapping is off by default, many more people will do this), and --fill's
> turning on hard-wrapping means that I have to type more when I want to change
> fill without turning on hard-wrapping.
Okay. So -b, --breaklonglines will be added. (Another behavior change.
And if there are lots of people who use nano to edit plain text and use
--fill=<number>, they will be surprised that this no longer switches on
automatic hard-wrapping and we might get complaints.)
> Specifically, my nanorc turns off hard-wrapping and sets fill to -1, but
> so many other things assume a fill of 72. This means that if I want to
> set fill to 72 temporarily, but keep hard-wrapping off, I have to use:
> nano -r 72 -w
> because the former option "helpfully" turns off the latter. Pico keeps
> them separate and doesn't have this problem.
Yes, but Pico doesn't have any rcfile that one may want to override.
If --fill did not override 'set nowrap', then nano would have needed
an additional option to switch hardwrapping back on. Having both a
--dowrap and a --nowrap option would have been somewhat strange.
Description: OpenPGP digital signature