[Nano-devel] Re: About the nano rewrite

[David Benbennick]

On 2/3/06, David Lawrence Ramsey <address@hidden> wrote:
> 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"?

Boost is pretty much required for good regex search.

We could have a fallback to the POSIX regex functions, I suppose.  The
problem is that they search in char* strings.  In Nano, that's no
problem, since the file is stored as a list of char*s.  In the new
version, the file is stored as a single Text object.  So to search
with the POSIX functions, you'd have to convert each line to a
temporary char*.  The code probably wouldn't be too complicated, but
it would be inefficient.  (If you like, I could implement it and run
some benchmarks to see exactly how inefficient.)

(Another alternative would be to include a version of the Boost regex
code with Nano.  The magic configure script could tell the Makefile to
use the included code if Boost isn't already installed on the system.)


Something I'd like to move away from with the new code is the
proliferation of precompiler variables.  I've intentionally left out
flags like DISABLE_JUSTIFY, etc.  The problem is that they make the
code very hard to maintain.  When's the last time you actually tested
Nano with DISABLE_JUSTIFY, DISABLE_MOUSE, and DISABLE_TABCOMP set, and
all the other features enabled?  All the different flags mean there
are hundreds of different "versions" of Nano to support.

I suppose it still makes sense to have a NANO_SMALL flag (there are
still people out there who use floppy boot disks, I guess), but I
don't think anyone really needs the ability to turn off help support
separately, for example.  (Anyway, with rebindable keys, if you don't
want help support you could just do something like "unbind ^G".)

> 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 guess that in a perfect world, any terminal running under X would
have support for any key combination supported by X (e.g.
Ctrl-Delete), and that key support would filter through curses to Nano
without Nano having to know about X at all.  Oh well; it's no surprise
that ncurses isn't perfect!