[Top][All Lists]

[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

From: Benno Schulenberg
Subject: Re: [Nano-devel] [PATCH 3/3] docs: an attempt at updating the documentation for the changed defaults
Date: Mon, 21 Jan 2019 09:51:55 +0100
User-agent: 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
>> hard-wrapping.)
> 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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]