nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] what to do about --disable-wrapping-as-root


From: David Lawrence Ramsey
Subject: Re: [Nano-devel] what to do about --disable-wrapping-as-root
Date: Thu, 24 Nov 2005 11:40:24 -0500
User-agent: Mozilla Thunderbird 1.0.7 (X11/20050923)

Jordi Mallach wrote:

<snip>

>The reason this was added is Debian's installer uses nano in the case
>when a user choses to edit APT's sources list at the end of the
>installation phase.
>
>By default, nano would be wrapping lines and many newbie users would
>mess up their file, which needs to be 1 line per source.

I've heard about this.  A lot of configuration files don't like wrapped
lines.

>Relying on a nanorc wasn't feasible because the system wasn't even
>completely installed yet, and shipping a default .nanorc for root in
>the nano package is a hack which I really dislike.

I suppose you'd dislike temporarily turning on nowrap in /etc/nanorc in
the package even more, then, since it's even more hackish.  Am I right?

>Making debian-installer call nano --no-wrap is equally ugly, because
>the installer doesn't actually call nano, it calls "editor", which is a
>symlink to the current default text editor in the system. At install
>time, this is nano. The idea is that you call "editor" with no
>arguments and it "just works".

Understood.  To think that this all comes down to Pico's having a bad
default (for us) in this case.

>So that left us with --disable-wrapping-as-root.
>
>My head is spinning a bit today, so I'm not sure if your proposal fixes
>any of these. Does it?

It depends.  Adding the .nanorc for root would only apply if nano were
built with .nanorc support.  nano-tiny, on the other hand, would have
all wrapping disabled.  So if nano-tiny is used by the installer instead
of the normal version, then it would still work the way you'd expect.

(The only other way around this would be a configure option that would
reverse the wrapping default and the associated option, but that would
be even weirder and even less compatible with Pico...)





reply via email to

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