nano-devel
[Top][All Lists]
Advanced

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

Re: [Nano-devel] Color patch


From: David Lawrence Ramsey
Subject: Re: [Nano-devel] Color patch
Date: Thu, 11 Sep 2003 00:30:24 -0700 (PDT)

Brand Huntsman:

<snip>

>> However, as for loading a nanorc from the current directory, the
>> effects of doing so could probably be accomplished by much simpler
>> means such as allowing nano to read default values from comments at
>> the beginning of files (cf. how vi does this; I forget the
>> terminology at the moment).
>
>What about a nanorc command like:
>
>       for "some-file" "~/some-directory/*"
>       set tabsize 8
>
>It would support set and unset commands below it and apply them to a
>file or all files in a directory and subdirectories.

The problem with that is that you'd have to make sure that the files
were all in one directory or specify each file individually, which might
end up being a major inconvenience.  Specifying the commands in the
files themselves doesn't have this problem.

>> (Note that there may be a few changes to the color code in the
>> future, as explained in my other email; however, they shouldn't be
>> anything major.)
>
>The "bright" background prefix?

No, the changes needed to convert nano to use display_string(), which
I'm almost done porting from DB's patch.  In any case, they mainly
affect the regex-displaying code in winio.c, which your patch doesn't
touch, so it may not be a problem after all.

>> I've tried the new nanorc syntax file out.  It works well afaict and
>> it isn't that different from the old version, so it's in.  I'll look
>> at the others soon.  Thanks.
>
>I've fixed some problems and made some tweaks/additions to my syntax
>files, so you might want to wait until I send the new files.

I'll do that.

----------

>http://bespin.org/~qz/nano-1.2.2-color.patch

<snip>

>The new regular expression code reduced the memory footprint by 1.3meg
>with my nanorc file. I used it to write most of the code in this patch
>and I had no problems. This patch does not fix the regexec() memory
>leak.

Cool.  I haven't had enough time to really test it yet, but I'll do that
soon.  I have noticed when testing it with all the regexes in
nanorc.sample that it doesn't like the fact that the "mutt" syntax
doesn't specify a file extension regex.  Is a file extension regex now a
requirement for all syntaxes?

One minor point of confusion: Since your nanorc regexes reference
"rebinddelete", which is only in the unstable CVS, I thought you were
using unstable CVS, but your patch is against 1.2.2.  Fortunately, the
parts of the code that your patch changes haven't diverged much from the
1.2.2 versions, so it was relatively easy to port.  I had to make the
following changes in the course of porting it, though:

- The -d option is already used as the short alias of --rebinddelete, so
it can't be used to display syntaxes.  I moved the option to -P for now,
since -d/-D, -i/-I, -s/-S, and -p were already used as well.

- The SAMELINEWRAP flag is only used in nano.c, so I converted it from a
flag to a static int in nano.c instead.  (Rationale: A flag is needed
when a variable is a boolean value and needs to be visible across
different files; otherwise, a static int for the one file, or a
temporary int for the one function, should be used in order to keep
things simple.)  This meant that there was one free flag value
available, so it was possible to convert display_syntax from a global
int to a flag of the same name, which I did.

- None of the long display options use hyphens.  Therefore, for
consistency, I changed the flag from --display-syntax to
--displaysyntax.

- I converted the C++-style comments to C-style comments.

The ported version is attached.  If possible, would you make patches
against the unstable CVS from now on?  Thanks.


_____________________________________________________________
Sluggy.Net: The Sluggy Freelance Community!

Attachment: nano-1.2.99-color.patch
Description: Binary data


reply via email to

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