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.

Reply via email to