[Top][All Lists]
[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