[Top][All Lists]

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

Re: About the nano rewrite (Was: Re: [Nano-devel] deleting whole words)

From: David Benbennick
Subject: Re: About the nano rewrite (Was: Re: [Nano-devel] deleting whole words)
Date: Sun, 29 Jan 2006 19:47:15 -0500

On 1/29/06, David Lawrence Ramsey <address@hidden> wrote:
the keys you identify as the
> Undo/Redo keys don't seem to do anything, and I'm not sure how to hack
> it so that they work, because the file appears to be a stub.

There's a new version of the code at  The new version
has rebindable keys. wasn't supposed to be there; it's gone now.  The undo code is
in  I suspect that what you did is type some
characters, then hit ^Z?  In the old version, undoing wouldn't become
active until you did something destructive (like delete or cut).  I've
changed it a bit, though it still doesn't do exactly the "right

> (I accidentally
> deleted the Boost library from my system, and SourceForge is down for
> maintenance at the moment, so I can't download it again yet to give you
> more details.)

I'll wrap the code that needs Boost in precompiler flags.  It's only
used for regex searching, anyway.  I'll send another email when that's

> 1. Why the switch to C++, and how far down the road to C++ is it going
> to go, so to speak?  In other words, is it going to be "C-like" C++, or
> "full" C++?  I ask because one of my pet peeves with the latter kind of
> C++ is how it can become so horribly complex that it's difficult to
> maintain

The rewrite uses a Text class, which actually does all the magic of
storing the file.  That magic data structure was written in C++ by
someone else (see the kubux/ directory in the tar file linked above). 
That's the only reason I changed to C++.

The Text class does use "full" C++; in fact, it doesn't compile
correctly except in the newer versions of g++.  Possibly that issue
can be fixed.

The actual editor code, which I wrote, doesn't use nasty C++ syntax. 
Even if I wanted to, I don't know that much C++.  It does use classes
(for example, there's a TextBuffer class; when you have 7 buffers open
you have 7 TextBuffer objects).  It also uses the STL, which makes
some things a WHOLE lot easier.  See, for example,

> 2. Some of the code appears to be derived from an older version of nano.
> I know that this is a rewrite, but is there going to be any effort to
> merge some of the still-useful changes in what will be the 1.4 branch
> once it comes out, such as the optimized display routines (which are
> very noticeable when running nano 1.3.x over a slow remote connection,
> as opposed to nano 1.2.x) and the various improvements merged from your
> behemoth patch from 2003?  (If so, I can certainly help with it.)

Sure.  You're probably seeing the fact that was written
a year ago, and Nano has added features since then.  It's certainly
intended to be feature-compatible eventually.  The display routine in
the new version is still very primitive---it can't even show long
lines.  So eventually that has to be fixed.

> The problem is what to do when the keypad support for a given terminal
> is broken.  If keypad support is working, you can just check for Escape
> KEY_DC or Escape Ctrl-8 (depending on whether the -d option is used),
> but if it isn't, there are all sorts of potential timing problems.  How
> do you easily tell the difference between Escape (Escape [ 3 ^) for
> Ctrl-Delete under rxvt-unicode, and (Escape Escape [) (3 ^) for Ctrl-[ 3
> ^ under rxvt-unicode?  And how do you deal with those terminals that
> don't differentiate between Delete and Ctrl-Delete, such as the Linux
> console?

Good point.  I have no idea.

I just want to point out that in the rewritten code, Shift-Delete
works like Delete.  In Nano, it does nothing.  It's a matter of
binding the ncurses key KEY_SDC, in addition to KEY_DC.  The same goes
for Shift-home and Shift-end (KEY_SHOME and KEY_SEND).

Another feature of the new code I'd like to point out is that you can
resize the window while in a menu, without being kicked out of the

reply via email to

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