Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults

From:

David Ramsey

Subject:

Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults

Date:

Tue, 11 Dec 2018 13:14:21 -0600

Benno Schulenberg:
> That's not been decided yet. There has been far too little response
> to the proposal.
I meant it in the sense of "while we're thinking about it."
> I used to have 'set quiet' in my .nanorc so that I wouldn't get a
> barrage of warnings when checking how an older version of nano worked
> in some situation. But I've had it commented out now for a while and
> cope with the barrage, so I guess it's fine to remove it. Patch is
> coming up.
Okay.
> But this poses the question: Pico recognizes -q nowadays. Should nano
> ignore it for "compatibility"?
Pico seems to have had -q for awhile, and we can't really ignore it for
compatibility because we don't have the functionality it affects:
reading termcap instead of terminfo is something handled at the ncurses
level, I think? If we did have that functionality on by default, then
ignoring -q for compatibility would make sense.
On the other hand, no one's ever complained about the incompatibility,
most likely because Pico doesn't even have the option unless it's
specially compiled.
> (We are not compatible anyway: -W does something else, all of Pico's
> color options don't work for nano, and even -d does not work as in
> Pico nowadays.)
I figure we're compatible enough. If you notice, Pico finally got the
ability to search backwards for text: ^W^P. We couldn't do so in that
way because ^P is the equivalent of the Up arrow, which means it's
already used for history.
(And how does -d not work as in Pico? I've done some quick testing, and
I can't see a difference in how Delete and Backspace behave under it
versus how they behave in Pico.)