nano-devel
[Top][All Lists]
Advanced

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

Re: [Nano-devel] Color patch


From: delta
Subject: Re: [Nano-devel] Color patch
Date: Thu, 11 Sep 2003 18:26:48 -0600

On Thu, 11 Sep 2003 00:30:24 -0700 (PDT)
David Lawrence Ramsey <address@hidden> wrote:


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

I don't understand what you mean by 'Specifying the commands in the
files', I don't want to eadd a 'set tabsize 8' comment to every file in
the nano-1.2.2 directory. It would be quicker and easier to add 'for
"~/nano-1.2.2/" ; set tabsize 8" to ~/.nanorc.

The code would simply test the first character of the filename, if '/'
it would compare to each of the FOR patterns. Otherwise it would prepend
`pwd` and then do the comparisons. It would probably be better if the
asterik wasn't used and the code could detect the trailing '/' and would
only compare the first N characters of the filename, where N is the
length of the pattern.

The only problem I see is with multibuffers, does each buffer have its
own settings such as tabsize or do all buffers share settings?


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

I didn't think about syntaxes with no extensions, they should be
allowed. My next patch will handle them.


> 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 nanorc file was for CVS, my patch was not. Sorry about that.


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

Ok.


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

I'm not sure what you're talking about but --displaysyntax would
shutdown nano before loading files. It parses the nanorc files, displays
each syntax and terminates.


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

Oops, four of those comments shouldn't be in the patch and I forgot to
finish the TODO comment.


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

I will make patches against 1.2.2 and CVS.

Does savannah generate nightly CVS tarballs? I'm behind a proxy and
can't access CVS via pserver, gserver or https. I would rather not
download each file manually through viewcvs. :)


-- 
Brand Huntsman -- http://www.qzx.com
Linux 2.4.21 (i686 451MHz) up 45 days 13:14 hours, 1292636 procs




reply via email to

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