Re: syntax borked
On Tue, 5 Sep 2006, A.J.Mechelynck wrote:
The gentoo package managing system need not be aware of your own-compiled Vim,
any more that my SuSE package managing system is aware of my Vim 7.0.83 (e.g.,
it won't list it if I do rpm -qa |grep vim).
But I suppose I would need to recompile vim due to changes in the gentoo
system (e.g., after upgrading gcc/glibc)?
[...]
796 for ([EMAIL PROTECTED]){
797 $heavy{$light[$_-1]}{$numbers[$_-1]}=$heavy[$_-1];
798 }
It doesn't. After pasting into an empty buffer via the clipboard,
block-deleting the column of numbers (from the left margin up to, but not
including, the s in sub at top and the last } at bottom) and setting
'filetype' to perl, I see all reserved words in brown, identifiers starting @
or $ in green including a preceding backslash if present, the identifier D
also in green, strings and numbers in pink with the exception of
backslash-escaped single quotes which are in mauve, regular expressions in
pink and mauve between brown slashes, and the rest in black, all of it on a
white background (this is gvim) from top to bottom of the text. The only thing
doubtful (to me) is that, inside the double-quoted strings, ${logdir} is in
pink but $! is in green.
In version 6.4, ${logdir} appears with the same colour as the rest of
the surrounding quoted string. I think this is normal. It would be
better to make it the same colour as other variables, like $!, but the
developer probably didn't think about it.
My Vim distribution uses ftplugin/perl.vim by Dan Sharp (2005 Dec 16) and
syntax/perl.vim by Nick Hibma (2006 Aug 9).
It appears there is a bug in the syntax file (see reply by Peter Hodge).
This brings up the question: How to install a syntax file without
poluting the distribution system? In gentoo, the file is (for version
6.4):
/usr/share/vim/vim64/syntax/perl.vim
Replacing this is not a good idea, since it would be replaced next time
I updated vim in gentoo. So, is there a way to tell vim where to look
for [some] syntax files? (Something like /usr/local/share/...)?
And about the indenting problem? Could you check with your vim and the
above piece of code? If you place the cursor on line 796 and press 'o'
in normal mode, it should open a line with the cursor above the '$' of
$heavy. What happened to me is that the cursor would be below the 'f'
of for.
Thanks a lot.
Regards,
Jorge
Re: syntax borked
On Tue, 5 Sep 2006, Peter Hodge wrote:
Hello Jorge,
The problem is solved if you change this line:
768 sub reloadlist{
to this:
768 sub reloadlist {
It looks as though it is a bug in the perl syntax file. You should send the
maintainer an email with your perl code snippet, and he should be able to fix
it. It probably never even crossed his mind that someone might leave out the
whitespace there.
Thanks. The syntax file worked with version 6.4, so probably he just
accidentaly deleted something...
Regards,
Jorge
Re: syntax borked
--- Jorge Almeida [EMAIL PROTECTED] wrote: It appears there is a bug in the syntax file (see reply by Peter Hodge). This brings up the question: How to install a syntax file without poluting the distribution system? In gentoo, the file is (for version 6.4): /usr/share/vim/vim64/syntax/perl.vim Replacing this is not a good idea, since it would be replaced next time I updated vim in gentoo. So, is there a way to tell vim where to look for [some] syntax files? (Something like /usr/local/share/...)? Well, there was a bug in the older syntax file I used (the one from 2005), but the newer syntax file I downloaded is fine. If you don't want to put the new syntax file in your home directory (~/.vim/syntax/perl.vim), you can also put it in /usr/share/vim/vimfiles/syntax/perl.vim. That directory should already be scanned by default ... check the value of 'runtimepath' to be sure. And about the indenting problem? Could you check with your vim and the above piece of code? If you place the cursor on line 796 and press 'o' in normal mode, it should open a line with the cursor above the '$' of $heavy. What happened to me is that the cursor would be below the 'f' of for. The indenting works fine for me, without installing any new indent scripts. Have you enabled 'autoindent' and/or 'smartindent'? regards, Peter On Yahoo!7 Check out PS Trixi - The hot new online adventure http://www.trixi.com.au
Re: syntax borked
On Tue, 5 Sep 2006, Peter Hodge wrote: Well, there was a bug in the older syntax file I used (the one from 2005), but the newer syntax file I downloaded is fine. If you don't want to put the new syntax file in your home directory (~/.vim/syntax/perl.vim), you can also put it in /usr/share/vim/vimfiles/syntax/perl.vim. That directory should already be scanned by default ... check the value of 'runtimepath' to be sure. How to check? Anyway, I think I'll settle to put it in ~/.vim/syntax. I'm recompiling vim 7.0.17 now, and will install the current syntax file. The indenting works fine for me, without installing any new indent scripts. Have you enabled 'autoindent' and/or 'smartindent'? Yes. And I didn't change my .vimrc, which works OK with 6.4. Thanks. Regards, Jorge
Re: syntax borked
Jorge Almeida wrote:
On Tue, 5 Sep 2006, A.J.Mechelynck wrote:
The gentoo package managing system need not be aware of your own-compiled Vim,
any more that my SuSE package managing system is aware of my Vim 7.0.83 (e.g.,
it won't list it if I do rpm -qa |grep vim).
But I suppose I would need to recompile vim due to changes in the gentoo
system (e.g., after upgrading gcc/glibc)?
[...]
If you upgrade the compiler, there should be no need to recompile
everything immediately, unless it doesn't work with the new libraries.
The next time there are _vim_ bugfixes, you ought to be able to use the
new version of the compiler with no trouble. The only thing is, if you
install or uninstall any packages that Vim uses (just as you would do if
you change your configuration settings), you should run make reconfig
in the src/ subdirectory to make sure that the configure cache is voided
and that your configuration settings are checked against the new state
of your software.
796 for ([EMAIL PROTECTED]){
797 $heavy{$light[$_-1]}{$numbers[$_-1]}=$heavy[$_-1];
798 }
It doesn't. After pasting into an empty buffer via the clipboard,
block-deleting the column of numbers (from the left margin up to, but not
including, the s in sub at top and the last } at bottom) and setting
'filetype' to perl, I see all reserved words in brown, identifiers starting @
or $ in green including a preceding backslash if present, the identifier D
also in green, strings and numbers in pink with the exception of
backslash-escaped single quotes which are in mauve, regular expressions in
pink and mauve between brown slashes, and the rest in black, all of it on a
white background (this is gvim) from top to bottom of the text. The only thing
doubtful (to me) is that, inside the double-quoted strings, ${logdir} is in
pink but $! is in green.
In version 6.4, ${logdir} appears with the same colour as the rest of
the surrounding quoted string. I think this is normal. It would be
better to make it the same colour as other variables, like $!, but the
developer probably didn't think about it.
My Vim distribution uses ftplugin/perl.vim by Dan Sharp (2005 Dec 16) and
syntax/perl.vim by Nick Hibma (2006 Aug 9).
It appears there is a bug in the syntax file (see reply by Peter Hodge).
This brings up the question: How to install a syntax file without
poluting the distribution system? In gentoo, the file is (for version
6.4):
/usr/share/vim/vim64/syntax/perl.vim
Replacing this is not a good idea, since it would be replaced next time
I updated vim in gentoo. So, is there a way to tell vim where to look
for [some] syntax files? (Something like /usr/local/share/...)?
Drop it as $VIM/vimfiles/syntax/perl.vim (i.e., IIUC,
/usr/share/vim/vimfiles/syntax/perl.vim), creating any needed
directories in the process; it will then be loaded before
$VIMRUNTIME/syntax/perl.vim, and the latter, seeing that a syntax script
has already been loaded, should terminate early without doing anything.
Of course, if someday you upgrade $VIMRUNTIME/syntax/perl.vim to
something _more recent_ than $VIM/vimfiles/syntax/perl.vim, you should
remove the latter manually.
And about the indenting problem? Could you check with your vim and the
above piece of code? If you place the cursor on line 796 and press 'o'
in normal mode, it should open a line with the cursor above the '$' of
$heavy. What happened to me is that the cursor would be below the 'f'
of for.
First, do :filetype with no arguments. If it says (among other things)
indent:OFF then you're not using filetype-related indenting and you
need :filetype indent on or :filetype plugin indent on somewhere in
your vimrc (it can be done implicitly by sourcing
$VIMRUNTIME/vimrc_example.vim).
My $VIMRUNTIME/indent/perl.vim is dated 2005 Sep 07 (by Rafael
Garcia-Suarez). If yours is the same or later, IMHO you should contact
the maintainer. If it is earlier, check the URI in the file's headings.
Thanks a lot.
Regards,
Jorge
Best regards,
Tony.
Re: syntax borked
Jorge Almeida wrote: On Tue, 5 Sep 2006, Peter Hodge wrote: Well, there was a bug in the older syntax file I used (the one from 2005), but the newer syntax file I downloaded is fine. If you don't want to put the new syntax file in your home directory (~/.vim/syntax/perl.vim), you can also put it in /usr/share/vim/vimfiles/syntax/perl.vim. That directory should already be scanned by default ... check the value of 'runtimepath' to be sure. How to check? :set runtimepath? See the default for it at :help 'runtimepath' Anyway, I think I'll settle to put it in ~/.vim/syntax. I'm recompiling vim 7.0.17 now, and will install the current syntax file. The indenting works fine for me, without installing any new indent scripts. Have you enabled 'autoindent' and/or 'smartindent'? Yes. And I didn't change my .vimrc, which works OK with 6.4. Thanks. Regards, Jorge Best regards, Tony.
Re: syntax borked
On Tue, 5 Sep 2006, A.J.Mechelynck wrote: Jorge Almeida wrote: On Tue, 5 Sep 2006, Peter Hodge wrote: Best regards, Tony. Thanks again for your help. Regards, Jorge
Re: syntax borked
Dnia poniedziałek, 4 września 2006 16:44, Jorge Almeida napisał: I've upgraded to vim-7.0.17. I don't know which version I had before, probably 6.4. I run linux (gentoo). After upgrading, syntax for perl seems to have gone to the trash. Colours appear chaotic and pressing 'o' in normal mode opens a new line but without the proper identation. How can such a thing happen? For syntax: you probably have some personalized syntax files which clash with default Vim7 ones. Changes required with spell checking could cause that effect. Check your .vim directory (and .vimrc file) and remove/comment all your definitions for perl files. Later you can reintroduce them carefully. m. -- W każdym z nas drzemie świnia. Ale u niektórych cierpi na bezsenność
Re: syntax borked
On Mon, 4 Sep 2006, Mikolaj Machowski wrote: For syntax: you probably have some personalized syntax files which clash with default Vim7 ones. Changes required with spell checking could cause that effect. Check your .vim directory (and .vimrc file) and remove/comment all your definitions for perl files. Later you can reintroduce them carefully. No, no personalized syntax files for perl. Only a few mappings, which still work... Google shows there are other people affected, but no solution... Thanks. -- Jorge Almeida
Re: syntax borked
Jorge Almeida wrote: I've upgraded to vim-7.0.17. I don't know which version I had before, probably 6.4. I run linux (gentoo). After upgrading, syntax for perl seems to have gone to the trash. Colours appear chaotic and pressing 'o' in normal mode opens a new line but without the proper identation. How can such a thing happen? This doesn't seem vim anymore. What can I do? There are several things you can do, independently of each other: - Upgrade to 7.0.083 - Change colorscheme, or write your own - Use the command :filetype indent on or :filetype indent off to switch filetype-related indenting on or off. When on, it overrides 'autoindent' and 'smartindent'. If you decide to turn it off, check that these latter two options are set as you want them, and since they are boolean options, don't forget the question marks in :verbose set autoindent? smartindent? - Contact the maintainer(s) of the perl plugins ftplugin/perl.vim and syntax/perl.vim Best regards, Tony.
Re: syntax borked
On Mon, 4 Sep 2006, A.J.Mechelynck wrote: I already downgraded to 6.4. Vim is just not a package I can afford to do without... Of course I hope to be able to upgrade someday. There are several things you can do, independently of each other: - Upgrade to 7.0.083 Not a good option for me. Version 7.0.17 is the one considered stable in gentoo, and I don't like to risk the bleeding edge with main packages. - Change colorscheme, or write your own I had a costumized colour scheme, which worked before, and still works now, after downgrading. But note that colour is not the only problem. Indenting went away, too. I checked my .vimrc. It has filetype plugin indent on. I also checked the differences between new and old /etc/vim/vimrc. They seem trivial. BTW, I'm not sure I understand about colour schemes: what I costumized are things like the colour of the selected area in visual mode and such. I didn't touch anything related with filetypes. With the new version, the problem is not that the colours are not to my liking, it's that they are synctatical nonsense (same keyword sometimes coloured, sometimes not, blocks of code all pink for no apparent good reason,...). - Use the command :filetype indent on or :filetype indent off to switch filetype-related indenting on or off. When on, it overrides 'autoindent' and 'smartindent'. If you decide to turn it off, check that these latter two options are set as you want them, and since they are boolean options, don't forget the question marks in :verbose set autoindent? smartindent? Will try this next time I upgrade. - Contact the maintainer(s) of the perl plugins ftplugin/perl.vim and syntax/perl.vim But what can brake such features? I read the manual for changes and new features, and found nothing relevant (except for the new parentesis highlightening, which I promptly got rid of). Best regards, Tony. Thanks, Jorge
Re: syntax borked
Jorge Almeida wrote: On Mon, 4 Sep 2006, A.J.Mechelynck wrote: I already downgraded to 6.4. Vim is just not a package I can afford to do without... Of course I hope to be able to upgrade someday. There are several things you can do, independently of each other: - Upgrade to 7.0.083 Not a good option for me. Version 7.0.17 is the one considered stable in gentoo, and I don't like to risk the bleeding edge with main packages. I don't know about gentoo, but packaged distributions are always several steps behind the real world. The 66 patches between 7.0.17 and 7.0.83 don't make the latter bleeding-edge and the former stable; rather, they make the latter up-to-date and the former obsolescent. See at http://ftp.vim.org/pub/vim/patches/7.0/ (http://, not ftp://) what these patches are all about; and see at http://users.skynet.be/antoine.mechelynck/vim/compunix.htm how to compile Vim for yourself from Bram Moolenaar's latest sources without waiting for gentoo or somebody to compile and package them. It's really easy once you get the hang of it. - Change colorscheme, or write your own I had a costumized colour scheme, which worked before, and still works now, after downgrading. But note that colour is not the only problem. Indenting went away, too. I checked my .vimrc. It has filetype plugin indent on. I also checked the differences between new and old /etc/vim/vimrc. They seem trivial. BTW, I'm not sure I understand about colour schemes: what I costumized are things like the colour of the selected area in visual mode and such. Think of a Vim color scheme as you would of a skin or theme for another program. Basically, a colorscheme is a script which takes all the color-related statements (:highlight, mostly) out of your vimrc and into a separate script so you can change colors at will without messing up everything else in your vimrc. I'm attaching a fairly simple colorscheme which is the one I use. You can apply it as-is (by dropping it into ~/.vim/colors/ -- make the directory if it doesn't exist -- and adding colorscheme almost-default to your vimrc) or change it to your heart's content. There are also standard colorschemes in the Vim distribution (at $VIMRUNTIME/colors/*.vim), and you can download others from the Web, e.g. at vim-online. In gvim, all available colorschemes on your computer are listed in the Edit - Color Scheme menu. I didn't touch anything related with filetypes. With the new version, the problem is not that the colours are not to my liking, it's that they are synctatical nonsense (same keyword sometimes coloured, sometimes not, blocks of code all pink for no apparent good reason,...). A block of code all pink can be a symptom of an unbalanced quotation mark somewhere. Otherwise, send me one of your perl source files, or a URI to it, and I'll tell you how it looks in my gvim 7.0.83. Tell me what looked wrong in your 7.0.17 and I'll tell you if it looks the same here. But since I'm not a perl programmer myself, it may be that I can tell you how it looks but not necessarily why it looks that way. - Use the command :filetype indent on or :filetype indent off to switch filetype-related indenting on or off. When on, it overrides 'autoindent' and 'smartindent'. If you decide to turn it off, check that these latter two options are set as you want them, and since they are boolean options, don't forget the question marks in :verbose set autoindent? smartindent? Will try this next time I upgrade. - Contact the maintainer(s) of the perl plugins ftplugin/perl.vim and syntax/perl.vim But what can brake such features? I read the manual for changes and new features, and found nothing relevant (except for the new parentesis highlightening, which I promptly got rid of). Best regards, Tony. Thanks, Jorge Best regards, Tony. Vim color file Maintainer: Tony Mechelynck [EMAIL PROTECTED] Last Change: 2006 Aug 28 This is almost the default color scheme. It doesn't define the Normal highlighting, it uses whatever the colors used to be. Only the few highlight groups named below are defined; the rest (most of them) are left at their compiled-in default settings. Set 'background' back to the default. The value can't always be estimated and is then guessed. hi clear Normal set bg Remove all existing highlighting and set the defaults. hi clear Load the syntax highlighting defaults, if it's enabled. if exists(syntax_on) syntax reset endif Set our own highlighting settings white on red is not always distinct in the GUI: use black on red then hi Errorguibg=red guifg=black hi clear ErrorMsg hi link ErrorMsg Error show cursor line/column (if enabled) in very light grey in the GUI, underlined in the console hi CursorLine guibg=#F4F4F4 hi clear CursorColumn hi
Re: syntax borked
On Mon, 4 Sep 2006, A.J.Mechelynck wrote:
I don't know about gentoo, but packaged distributions are always several steps
behind the real world. The 66 patches between 7.0.17 and 7.0.83 don't make
the latter bleeding-edge and the former stable; rather, they make the
latter up-to-date and the former obsolescent. See at
http://ftp.vim.org/pub/vim/patches/7.0/ (http://, not ftp://) what these
patches are all about; and see at
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm how to compile Vim
for yourself from Bram Moolenaar's latest sources without waiting for gentoo
or somebody to compile and package them. It's really easy once you get the
hang of it.
In gentoo, compiling (emerging) vim means compiling 3 packages:
vim-core, vim and gvim. Assuming that the sources are likewise triple
(as opposed to the tripartition being a gentoo modification), I would
probably be able to compile it and install it to /usr/local without
confusing the gentoo system. But what about other packages related to
vim, which I may want to have installed some day (vimpython, vimpart,
whatever)?. I'm not sure I want to do this without knowing what really
causes the problems. But I'll take a look at the sites you mentioned.
- Change colorscheme, or write your own
I had a costumized colour scheme, which worked before, and still works
now, after downgrading. But note that colour is not the only problem.
Indenting went away, too. I checked my .vimrc. It has filetype plugin
indent on. I also checked the differences between new and old
/etc/vim/vimrc. They seem trivial.
BTW, I'm not sure I understand about colour schemes: what I costumized
are things like the colour of the selected area in visual mode and such.
Think of a Vim color scheme as you would of a skin or theme for another
program.
Basically, a colorscheme is a script which takes all the color-related
statements (:highlight, mostly) out of your vimrc and into a separate script
so you can change colors at will without messing up everything else in your
vimrc. I'm attaching a fairly simple colorscheme which is the one I use. You
can apply it as-is (by dropping it into ~/.vim/colors/ -- make the directory
if it doesn't exist -- and adding colorscheme almost-default to your vimrc)
or change it to your heart's content. There are also standard colorschemes
in the Vim distribution (at $VIMRUNTIME/colors/*.vim), and you can download
others from the Web, e.g. at vim-online. In gvim, all available colorschemes
on your computer are listed in the Edit - Color Scheme menu.
This is what I thought. But it seems completely orthogonal to filetype
issues...
I didn't touch anything related with filetypes. With the new version,
the problem is not that the colours are not to my liking, it's that they
are synctatical nonsense (same keyword sometimes coloured, sometimes
not, blocks of code all pink for no apparent good reason,...).
A block of code all pink can be a symptom of an unbalanced quotation mark
somewhere. Otherwise, send me one of your perl source files, or a URI to it,
I know. This sort of thing happens sometimes, but this time I opened a
file that looked OK before and is OK now after downgrading.
and I'll tell you how it looks in my gvim 7.0.83. Tell me what looked wrong
in your 7.0.17 and I'll tell you if it looks the same here. But since I'm not
a perl programmer myself, it may be that I can tell you how it looks but not
necessarily why it looks that way.
768 sub reloadlist{
769 my $self=shift;
770 opendir(D,$logdir) || do{
771 print Couldn\'t open directory ${logdir}: $!;
772 return 1;
773 };
774 my @heavy=grep(!/^\./, readdir(D));
775 closedir D || do{
776 print Couldn\'t close directory ${logdir}: $!;
777 return 1;
778 };
779 my @light=();
780 for (@heavy){
781 /^[^_]*_(.*)/;
782 push @light, $1;
783 }
784 my @numbers=();
785 my $number=0;
786 my $former='';
787 for (@light){
788 if($_ eq $former){
789 $number++;
790 }else{
791 $number=1;
792 }
793 push @numbers, $number;
794 }
795 my %heavy=();
796 for ([EMAIL PROTECTED]){
797 $heavy{$light[$_-1]}{$numbers[$_-1]}=$heavy[$_-1];
798 }
799 @light=sort @light;
800 $self-{'light'[EMAIL PROTECTED];
801 $self-{'heavyarr'[EMAIL PROTECTED];
802 $self-{'numbers'[EMAIL PROTECTED];
803 $self-{'heavy'}=\%heavy;
804 return 1;
805 }
Don't bother about the code. Its logic is wrong, that's why I was
editing it. After line 777
Re: syntax borked
Jorge Almeida wrote:
On Mon, 4 Sep 2006, A.J.Mechelynck wrote:
I don't know about gentoo, but packaged distributions are always several steps
behind the real world. The 66 patches between 7.0.17 and 7.0.83 don't make
the latter bleeding-edge and the former stable; rather, they make the
latter up-to-date and the former obsolescent. See at
http://ftp.vim.org/pub/vim/patches/7.0/ (http://, not ftp://) what these
patches are all about; and see at
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm how to compile Vim
for yourself from Bram Moolenaar's latest sources without waiting for gentoo
or somebody to compile and package them. It's really easy once you get the
hang of it.
In gentoo, compiling (emerging) vim means compiling 3 packages:
vim-core, vim and gvim. Assuming that the sources are likewise triple
(as opposed to the tripartition being a gentoo modification), I would
probably be able to compile it and install it to /usr/local without
confusing the gentoo system. But what about other packages related to
vim, which I may want to have installed some day (vimpython, vimpart,
whatever)?. I'm not sure I want to do this without knowing what really
causes the problems. But I'll take a look at the sites you mentioned.
Tripartition into common/vim/gvim is a gentoo thing (though RedHat and
SuSE have something similar). Bram's official Vim sources are
downloaded from three archives: unix, extra and lang[uage] which are
unpacked on top of each other before compiling. Any bugfixes (83 of them
as I'm writing this) are then applied in ascending sequence (or you can
download up-to-date sources from cvs or subversion but I don't). Since
runtime files are not always patched in a timely fashion, it may be
useful to download (or rsync) them now and them from the runtime/
directory on the Vim ftp site (and its subdirectories except runtime/dos/).
Then you decide which configuration options you want to include (Normal,
Big or Huge features, with or without perl or python, which [or no] GUI
flavour etc.), configure checks that you've got the necessary software
including development stuff (and disables some features if you don't),
make compiles your executable (which, on Linux, can do double duty for
console Vim and gvim if it is GUI-enabled), then, if you're satisfied
that there is a newly-compiled executable and that it seems OK (for
instance, if ls -l src/vim shows today's datestamp and src/vim
--version shows all the features which you regard as important), you
run make install to move the executable into (by default)
/usr/local/bin/ and the runtime files into (by default, for version 7.0)
/usr/local/share/vim/vim70/. That's all. See my HowTo page mentioned
above for more details, including a sample bash script to set typical
catch-all configuration options.
The gentoo package managing system need not be aware of your
own-compiled Vim, any more that my SuSE package managing system is aware
of my Vim 7.0.83 (e.g., it won't list it if I do rpm -qa |grep vim).
[...]
A block of code all pink can be a symptom of an unbalanced quotation mark
somewhere. Otherwise, send me one of your perl source files, or a URI to it,
I know. This sort of thing happens sometimes, but this time I opened a
file that looked OK before and is OK now after downgrading.
and I'll tell you how it looks in my gvim 7.0.83. Tell me what looked wrong
in your 7.0.17 and I'll tell you if it looks the same here. But since I'm not
a perl programmer myself, it may be that I can tell you how it looks but not
necessarily why it looks that way.
768 sub reloadlist{
769 my $self=shift;
770 opendir(D,$logdir) || do{
771 print Couldn\'t open directory ${logdir}: $!;
772 return 1;
773 };
774 my @heavy=grep(!/^\./, readdir(D));
775 closedir D || do{
776 print Couldn\'t close directory ${logdir}: $!;
777 return 1;
778 };
779 my @light=();
780 for (@heavy){
781 /^[^_]*_(.*)/;
782 push @light, $1;
783 }
784 my @numbers=();
785 my $number=0;
786 my $former='';
787 for (@light){
788 if($_ eq $former){
789 $number++;
790 }else{
791 $number=1;
792 }
793 push @numbers, $number;
794 }
795 my %heavy=();
796 for ([EMAIL PROTECTED]){
797 $heavy{$light[$_-1]}{$numbers[$_-1]}=$heavy[$_-1];
798 }
799 @light=sort @light;
800 $self-{'light'[EMAIL PROTECTED];
801 $self-{'heavyarr'[EMAIL PROTECTED];
802 $self-{'numbers'[EMAIL PROTECTED];
803 $self-{'heavy'}=\%heavy;
804 return 1;
805 }
Re: syntax borked
Hello Jorge,
The problem is solved if you change this line:
768 sub reloadlist{
to this:
768 sub reloadlist {
It looks as though it is a bug in the perl syntax file. You should send the
maintainer an email with your perl code snippet, and he should be able to fix
it. It probably never even crossed his mind that someone might leave out the
whitespace there.
You can fix your copy of the perl syntax by changing this line:
363 syn match perlFunctionName \h\w*[^:] contained
to this:
363 syn match perlFunctionName \h\w*[^:{] contained
regards,
Peter
Vim does a very good job dealing with perl syntax. This problem came as
a really bad surprise.
Jorge
Do you Yahoo!?
Take part in Total Girls Ultimate Slumber Party and help break a world record
http://www.totalgirl.com.au
Re: syntax borked
--- A.J.Mechelynck [EMAIL PROTECTED] wrote:
It doesn't. After pasting into an empty buffer via the clipboard,
block-deleting the column of numbers (from the left margin up to, but
not including, the s in sub at top and the last } at bottom) and
setting 'filetype' to perl, I see all reserved words in brown,
identifiers starting @ or $ in green including a preceding backslash if
present, the identifier D also in green, strings and numbers in pink
with the exception of backslash-escaped single quotes which are in
mauve, regular expressions in pink and mauve between brown slashes, and
the rest in black, all of it on a white background (this is gvim) from
top to bottom of the text. The only thing doubtful (to me) is that,
inside the double-quoted strings, ${logdir} is in pink but $! is in green.
My Vim distribution uses ftplugin/perl.vim by Dan Sharp (2005 Dec 16)
and syntax/perl.vim by Nick Hibma (2006 Aug 9).
That explains alot, then. I was using perl syntax by Nick Hibma, October 18,
2005 (probably what was packaged with vim 7 when it was released). Downloading
the latest version from ftp://ftp.vim.org/pub/vim/runtime/syntax/perl.vim
corrected the problem.
regards,
Peter
On Yahoo!7
360°: Share your blog, photos, interests and what matters most to you
http://www.yahoo7.com.au/360
