nano-devel
[Top][All Lists]
Advanced

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

[Nano-devel] Re: About the nano rewrite


From: David Lawrence Ramsey
Subject: [Nano-devel] Re: About the nano rewrite
Date: Fri, 03 Feb 2006 00:19:47 -0500
User-agent: Thunderbird 1.5 (X11/20051201)

David Benbennick wrote:

<snip>

> There's a new version of the code at
> http://www.cam.cornell.edu/~dbenbenn/new-nano.tar.gz.  The new version
> has rebindable keys.

Oh good.

> Undo.cc wasn't supposed to be there; it's gone now.  The undo code is
> in TextBuffer.cc:do_undo().  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
> thing".

Okay.  Thanks for the explanation.  I'll try it out as soon as I can.

<snip>

> 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
> done.

By the way, is the dependency on Boost a temporary holdover from the
original kubux code, or is it going to be an integral part of "onan"?

<snip>

> 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.

I hope so.  If you couldn't tell already, I'm somewhat paranoid when it
comes to compatibility.  (One of the reasons I didn't go with storing
everything in wchar_t strings, as you did in your old UTF-8 patch, was
to retain compatibility with older compilers that didn't support
wchar_t's at all, and not split nano into two UTF-8-enabled and
ASCII-enabled versions.)

> 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,
> TextBuffer.cc:do_next_word().

I don't mind classes per se; I only mind nasty syntax, as you put it,
and if that isn't there, I can handle it.

<snip>

> Sure.  You're probably seeing the fact that TextBuffer.cc 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.

Okay.  That's good to know.

<snip>

> Good point.  I have no idea.

Well, to elaborate a bit on the X11 idea, a few people have brought up
the idea of a graphical frontend for nano, but right now it seems about
as likely as the DJGPP port.  (Or even less so, as there have been
people who've said they have patches for it and never sent them, and one
person with a patch to add it to 1.0.8[!] that disables far more
functionality than necessary in the process.)  Besides, in order to
support an X11 frontend properly, nano would have to be decoupled from
curses in the first place, which would take yet another rewrite...

> 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).

Not true anymore as of current CVS.  Thanks for the heads up :)

> 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
> menu.

That's good.  Although nano's current behavior does match Pico's in this
respect, it's one thing I wouldn't mind changing.

----------

David Benbennick wrote:

<snip>

> The new version of
> http://www.cam.cornell.edu/~dbenbenn/new-nano.tar.gz now uses
>     #ifdef HAVE_BOOST
> around the regex code.  To turn it off, you'll have to edit the
> Makefile slightly.

Thank you.  I have Boost 1.33.1 (again), but it has no DESTDIR support,
which makes it extremely difficult to package properly, and it takes
several hours to build in any case, so I'll have to go without it for
the time being, or at least until I can file a bug report about the
DESTDIR support.





reply via email to

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