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 }
Don't bother about the code. Its logic is wrong, that's why I was
editing it. After line 777 or so, everything went pink. It didn't like
the "print" in line 776. As I said, it looks OK now, in 6.4. You'll
notice immediately if the same problem manifests with your vim.
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).
Vim does a very good job dealing with perl syntax. This problem came as
a really bad surprise.
Best regards,
Tony.
Thanks again.
Regards,
Jorge
Best regards,
Tony.
