nano-devel
[Top][All Lists]
Advanced

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

[Nano-devel] status of patches: 11/13


From: David Lawrence Ramsey
Subject: [Nano-devel] status of patches: 11/13
Date: Wed, 12 Nov 2003 23:28:30 -0800 (PST)

Yes, I know I've been quiet lately; I've just been busy again.  Sorry if
I'm keeping anyone waiting.  I've at least found time to do some things
in the past week and a half (and before, even if I haven't announced
them):

First, the fix for the delete key's sometimes malfunctioning at the
statusbar prompt is in CVS, as is the updated spec file.  I committed
the latter because since the changes were simple enough, and I got no
feedback on it in any case; if there are any problems with it, let me
know.  I also added a minor tweak to the Meta-W (search again) shortcut
entry to allow it to work in view mode, as ordinary search does.

Second, I've been going over the first of Brand Huntsman's color patches
some more.  It turns out that with -Wall enabled, there are some
warnings about variables' possibly being used uninitialized in
functions.  Note that some of these were in the code that was originally
from nanovarcinsert.patch.  The following patch has fixes for the
warnings, a restructuring of the error handling routines in
parse_include() that I had to do in the process of fixing the warnings,
and a few minor stylistic fixes (e. g. if/else statements shouldn't all
be on one line).  While I was in the rcfile code, I also removed a few
unneeded newlines at the end of nanorc errors.

http://pooka_regent.tripod.com/patches/nano/nano-1.3.0-color2-patch.txt

[Brand: I'm still applying both this and the color-memleak patch to my
local builds, and they both seem to be working fine.  I think I've
noticed the memleak patch in action: sometimes while scrolling through C
files in nano with color syntax highlighting on, it'll get slower and
then suddenly speed back up.  It's very nice, by the way.  Most of the
color patch looks good, but I have one question about it.

The code dealing with case insensitive color regex matches uses a
#defined flag value CTFLAG_INSENSITIVE.  Since you're using that instead
of a constant, it appears that you're leaving it open for other flags in
the future.  Is that the case?  If so, the flag should probably be
defined in nano.h with the other flags instead of local to rcfile.c, for
consistency.  I can fix that in the color2 patch on my end, but I'd like
to know what you intended first.

Also, regarding the question in your comments about whether file
extensions should be treated case insensitively: ".c" files are C source
files and ".C" files are C++ source files, so definitely not in all
cases.]

Third, after more testing and stumbling across a few more infinite
loops, I've concluded that nanodollar.patch, while it initially seemed
to work, is fundamentally broken in that (a) you only escape the one
loop if you do the replace, meaning that you couldn't refuse a replace
and continue properly, and (b) there were other infinite loop cases that
it didn't handle.  The first one of these that I hit was a forward regex
replace of "^$" with ""; I was originally trying to remove extra blank
lines from a file and, via the aforementioned replace, ended up
inadvertently replacing blank lines with themselves, during which the
cursor never moved beyond the first one.

I've gone back to the drawing board and, after a few incremental
attempts, finally replaced the nanodollar hack with a much cleaner fix
that has properly handled all the potential infinite loop cases I've
thrown at it so far.  It's in the following patch:

http://pooka_regent.tripod.com/patches/nano/nanoreplacefix4-patch.txt

Now, to avoid the possibility of its being broken in a similar way to
nanodollar.patch, I'd definitely like to get some outside testing done
on it before I put it in (and most likely try to get it approved to go
into the stable branch as well).  So would some people here please apply
this patch to the latest CVS, try the most bizarre, redundant forward
and backward regex replacements that they can think of, and let me know
if everything works as it should?  Thanks in advance.

The other patches from before are still much the same as ever, and I'll
get to them soon.


_____________________________________________________________
Sluggy.Net: The Sluggy Freelance Community!




reply via email to

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