[Top][All Lists]

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

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

From: delta
Subject: Re: [Nano-devel] status of patches: 11/13
Date: Thu, 13 Nov 2003 18:53:51 -0700

On Wed, 12 Nov 2003 23:28:30 -0800 (PST)
David Lawrence Ramsey <address@hidden> wrote:

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

Oops! '-Wall' should be on by default. :)

My memleak patch sometimes segfaults when resizing the window and I
don't know what causes it. The first patch is not affected and the
uninitialized variable in color.c did not fix the problem. The only
thing I can think of is that the resize handler is preempting
regexec_wrapper after it frees the regex_t but before it recompiles it.
I haven't looked into how resize works but could this be happening?

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

Increasing the '100' value in regexec_wrapper would increase the time
between pauses when scrolling. It would also increase nano's memory
usage slightly, as noted in the comment, but I don't think it would slow
down the regexec matches that much, at least not as much as it does when
regexec is using 100meg. I'll let someone else determine the best value.

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

I released a third patch about a week ago but was unable to let you know
due to connection problems. The new patch adds CTFLAG_DEFAULTCOLOR and
two unreleased patches will add CTFLAG_NEXT and CTFLAG_FORCED. These
flags are only used in parse_colors() and parse_rcfile() functions and
could be moved to nano.h but I don't see why you would want to make them

My patches are now located at

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


Brand Huntsman --
Gentoo Linux 2.4.21 [Celeron  451MHz]
up 57 days 6:54 hours, 2128517 procs

reply via email to

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