nano-devel
[Top][All Lists]
Advanced

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

Re: [Nano-devel] [RFC] a few things


From: Chris Allegretta
Subject: Re: [Nano-devel] [RFC] a few things
Date: Wed, 9 Apr 2014 11:28:48 -0400

On 4/9/14, Benno Schulenberg <address@hidden> wrote:
>
> Hi all,
>
> I'd like to hear your opinion on the following few points.
>
> 1)  Currently, when the user makes a mistake on the command line,
> nano blurts out 48 lines of usage text, scrolling the actual error
> message right off the screen.  (I then don't even bother to scroll
> back, but just do <Up> and look closely at what I typed.)  Would
> it not be better if nano just printed the error message plus one
> line saying "Type 'nano --help' for a list of options."?

Excellent, yes.

> 2)  The tiny version of nano does not provide the ability to search
> case-sensitively nor backwards, but does provide the ability to search
> for regular expressions.  The first ability costs almost no code, and
> the second just a few tiny fragments -- shouldn't they be included?
> Also, a tiny nano includes the ability to Search-and-replace (M-R)
> but not the ability to Search-for-next (M-W).  The latter costs just
> a bit of code -- shouldn't it be included in tiny?  Or should tiny
> exclude even more?  Regular expressions and even Replace?

indifferent to this; nano originally became the default debian editor
(brag brag brag) parlly because it was able to fit on the boot
floppies image.  Jordi or someone more Debian-ish can correct of I'm
operating under a misapprehension about that.

> 3)  Some years ago Dan Mahoney suggested [1] the addition of the
> feature of making not only tabs and spaces but also end-of-lines
> visible -- useful when in softwrap mode, where it can be difficult
> to see whether a line wraps or ends.  Would anyone else be interested
> in this feature?
>
> [1] https://lists.gnu.org/archive/html/nano-devel/2010-06/msg00000.html

As a flag or rcfile option?  Sure.

> 4)  Currently nano does nothing special when it is invoked with the
> name of 'pico'.  Should it?  Should it in that case try to resemble pico
> as closely as possible, in every menu?  It would allow nano itself to
> diverge a bit from this look (just the arragement of help lines) in an
> attempt to be more helpful (show ^\ Replace by default, for example).

That's by design (now anyway). It's part of the GNU Coding Standards,
http://www.gnu.org/prep/standards/standards.html#Program-Behavior

"Please don't make the behavior of a utility depend on the name used
to invoke it. It is useful sometimes to make a link to a utility with
a different name, and that should not change what it does.

Instead, use a run time option or a compilation switch or both to
select among the alternate behaviors."

That's one of the reasons we have 8 billion flags :-)

> 5)  The section "Editor Basics" in the texinfo documentation explains
> several things about nano -- like how to enter commands, how to use the
> mouse, and what the Title bar and Status bar are -- but it doesn't explain
> how the cutbuffer works (for example that consecutive ^Ks will add to the
> buffer, but that a ^K after any other key will overwrite it), and what the
> mark is and how it behaves (that a ^K will cut the whole marked section
> and unset the mark without saying so).  Would the addition of two sections,
> "The Cutbuffer" and "The Mark" be useful?  And should maybe even the man
> page contain a short section about the basic editing behaviour of nano?

I'm 100% for more thorough documentation.  It could even be added as a
task on the Savannah page if we want to ask for help writing it.



reply via email to

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