Re: Build broken -- Undefined references -- MinGW, vim with perl
Suresh Govindachar wrote: > > Tony wrote: > >Suresh Govindachar wrote: > >> > >> Solved with help from Brian Dessent on the MinGW mailing list. > >> > >> Add -lperl58 at the very end (location matters) of the last command. > >> > >> --Suresh > > > > This is understandable by assuming that the linker processes > > each object file or library once, in the order seen on the > > command line. Then any symbols unsatisfied so far will be looked > > for in the next lib at each step: and this implies that a symbol > > invoked only by a later lib won't be searched again in an > > earlier lib (unless, of course, its name is repeated further > > on). > > Not really -- for a build with dynamic support, there should not > be any need to add -lperl58. There is a shortcoming in if_perl.xs > (mentioned in another theread) that prevents the building of vim > with dynamic support for newer releases of ActivePerl perl. > > --Suresh My explanation was about "location matters", not about "lperl58 is required". Best regards, Tony. -- Bride, n.: A woman with a fine prospect of happiness behind her. -- Ambrose Bierce, "The Devil's Dictionary" --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Build broken -- Undefined references -- MinGW, vim with perl
Tony wrote: >Suresh Govindachar wrote: >> >> Solved with help from Brian Dessent on the MinGW mailing list. >> >> Add -lperl58 at the very end (location matters) of the last command. >> >> --Suresh > > This is understandable by assuming that the linker processes > each object file or library once, in the order seen on the > command line. Then any symbols unsatisfied so far will be looked > for in the next lib at each step: and this implies that a symbol > invoked only by a later lib won't be searched again in an > earlier lib (unless, of course, its name is repeated further > on). Not really -- for a build with dynamic support, there should not be any need to add -lperl58. There is a shortcoming in if_perl.xs (mentioned in another theread) that prevents the building of vim with dynamic support for newer releases of ActivePerl perl. --Suresh --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Build broken -- Undefined references -- MinGW, vim with perl
Suresh Govindachar wrote: > > > Solved with help from Brian Dessent on the MinGW mailing list. > > Add -lperl58 at the very end (location matters) of the last command. > > --Suresh This is understandable by assuming that the linker processes each object file or library once, in the order seen on the command line. Then any symbols unsatisfied so far will be looked for in the next lib at each step: and this implies that a symbol invoked only by a later lib won't be searched again in an earlier lib (unless, of course, its name is repeated further on). Best regards, Tony. -- This message contains 78% recycled characters. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Shortcoming of if_perl.xs
cc: Sven Verdoolaege -- where are you? Jan Dubois of ActiveState points out an issue with if_perl.xs: Jan Dubois wrote: > On Mon, 27 Aug 2007, Suresh Govindachar wrote: >> >> So ActiveState is "exporting" Perl_sv_2iv_flags and >> Perl_newXS_flags in a way that is different from the >> way they export other symbols. > > Nope, this is all incorrect. I've now downloaded the vim > sources to see what is really going on: > > The src/if_perl.xs file contains code to redefine all Perl > functions it assumes it uses to wrapper names, and then looks up > the real functions at runtime. That means that this file is > specific to the Perl version used to compile it and will need to > be updated for Perl 5.8.9. See for example: > > # if (PERL_REVISION == 5) && (PERL_VERSION >= 8) > # define Perl_sv_2pv_flags dll_Perl_sv_2pv_flags > # define Perl_sv_2pv_nolen dll_Perl_sv_2pv_nolen > # else > # define Perl_sv_2pv dll_Perl_sv_2pv > # endif > ... > #if (PERL_REVISION == 5) && (PERL_VERSION >= 8) > static char* (*Perl_sv_2pv_flags)(pTHX_ SV*, STRLEN*, I32); > static char* (*Perl_sv_2pv_nolen)(pTHX_ SV*); > #else > static char* (*Perl_sv_2pv)(pTHX_ SV*, STRLEN*); > #endif > > ... > > Similar code will be needed for sv_2iv_flags() and any other > new symbol. > > It is a bit awkward to do this for ActivePerl 822, as it > identifies itself as 5.8.8 because 5.8.9 has not been released > yet, so we don't know which additional features will still be > added. But internally AP822 is probably closer to what will be > 5.8.9 than to 5.8.8. > > Anyways, the problem is that if_perl.xs is coupled pretty > tightly to the Perl internals and needs updating whenever the > internals change. --Suresh --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
How to find out how symbols are exported
The Make_ming.mak file for gvim has the lines: ifdef PERL ifeq (no, $(DYNAMIC_PERL)) LIB += -lperl$(PERL_VER) endif endif So when building gvim with dynamic support for perl: 1) For older versions of ActivePerl, the build is successful without any explicit -lperl58 The linker somehow knows that perl58 related symbols that it cannot resolve will be resolved at runtime via perl58.dll 2) For the latest ActivePerl (build 822), when build is done without adding -lperl58 The linker somehow knows -- for almost all -- the perl58 related symbols that it cannot resolve, they will be resolved at runtime via perl58.dll For some reason, the linker demands that two particular symbols Perl_sv_2iv_flags and Perl_newXS_flags be resolved at link time via an explicit addition of -lperl58 So ActiveState is "exporting" Perl_sv_2iv_flags and Perl_newXS_flags in a way that is different from the way they export other symbols. Is it possible to examine perl58.dll and/or perl58.lib to figure out what's wrong in the way Perl_sv_2iv_flags and Perl_newXS_flags are being exported? Thanks, --Suresh --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Build broken -- Undefined references -- MinGW, vim with perl
Solved with help from Brian Dessent on the MinGW mailing list. Add -lperl58 at the very end (location matters) of the last command. --Suresh --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Build broken -- Undefined references -- MinGW, vim with perl
Earlier, I asked the dll gurus, > Latest response from Jan Dubois of ActiveState: >> On Fri, 24 Aug 2007, Suresh Govindachar wrote: >> >>> Sisyphus suggested linking with C:/opt/perl/lib/CORE/perl58.lib >>> (which does have the symbols in it) in the command that creates >>> if_perl.o and/or in the command that builds gvim.exe (which is >>> also the command that reports the missing references). >>> >>> But the build is supposed to use the library dynamically, rather >>> than be statically linked. So perl58.dll must tell the linker >>> that it will resolve the missing references at run time. >>> >>> Perhaps although ActiveState added code for the references, they >>> are not exposing them to the linker for dynamic use via >>> perl58.dll? Or is everything in a dll automatically visible? >> >> Perl_sv_2iv_flags is exported from perl58.dll. This symbols is >> being used by virtually every Perl module containing XS code >> because the SvIV() macro will expand into a call to it: >> >> [in sv.h] >> #define SvIV(sv) (SvIOK(sv) ? SvIVX(sv) : sv_2iv(sv)) >> ... >> #define sv_2iv(sv) sv_2iv_flags(sv, SV_GMAGIC) Note: grep -rl Perl_sv_2iv_flags C:\opt\perl/lib/Core results in: C:\opt\perl/lib/Core/embed.h C:\opt\perl/lib/Core/perl58.lib C:\opt\perl/lib/Core/proto.h So added -lperl58 to the command that generates if_perl.o and to the command that generates gvim.exe. The first command reported: gcc: -lperl58: linker input file unused because linking not done The second command resulted in the same undefined reference error. Just to be sure, I added -lblah to the second command, and got the new error message: c:\opt\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lblah --Suresh --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Possible bug in 'operatorfunc', g@, and / combination
On 8/27/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > Nikolai Weibull wrote: > > So it seems that there's something strange going on in what line is > > being set for the ] mark when performing a search under these > > conditions, coupled with patterns that match at the very beginning of > > a line. > There are a few special ways operators handle movements. Note that the > "/" is "exclusive", which means the end position of the cursor is not > included in the operated text. When this position is at the start of > the line, that line is not included. It's like the cursor ends up just > after the end of the previous line. Try it with "d/pat". This is > to make it Vi compatible. And mostly it does what you expect. I guess I confused myself when I tested this with "V/pat". Hm, I can't think of a good way to check if the motion was due to a search (/), as I could then add one to the end for this particular command, where I in fact want the motion to be inclusive. I can always do "g:/p\zsat", I suppose, but that's additional typing... nikolai --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Build broken -- Undefined references -- MinGW, vim with perl
.dll gurus, Latest response from Jan Dubois of ActiveState: > On Fri, 24 Aug 2007, Suresh Govindachar wrote: > >> Sisyphus suggested linking with C:/opt/perl/lib/CORE/perl58.lib >> (which does have the symbols in it) in the command that creates >> if_perl.o and/or in the command that builds gvim.exe (which is >> also the command that reports the missing references). >> >> But the build is supposed to use the library dynamically, rather >> than be statically linked. So perl58.dll must tell the linker >> that it will resolve the missing references at run time. >> >> Perhaps although ActiveState added code for the references, they >> are not exposing them to the linker for dynamic use via >> perl58.dll? Or is everything in a dll automatically visible? > > Perl_sv_2iv_flags is exported from perl58.dll. This symbols is > being used by virtually every Perl module containing XS code > because the SvIV() macro will expand into a call to it: > > [in sv.h] > #define SvIV(sv) (SvIOK(sv) ? SvIVX(sv) : sv_2iv(sv)) > ... > #define sv_2iv(sv) sv_2iv_flags(sv, SV_GMAGIC) --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Proposal: "Modes" for Vim
On 26/08/07, krischik <[EMAIL PROTECTED]> wrote: > My proposal (if you have not guessed already) is to merge more > separate plug ins into modes. What do you think about the idea? While I do not maintain any vim plugins, this suggestion makes sense to me. Richard --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Possible bug in 'operatorfunc', g@, and / combination
Nikolai Weibull wrote:
> I have the following function and binding:
>
> noremap g: :set operatorfunc=get_command_mode_rangeg@
>
> function! s:get_command_mode_range(type)
> let b = line("'[")
> let e = line("']")
>
> if b < e
> let range = '.,+' . (e - b)
> elseif b == e
> let range = '.'
> else
> let range = '.,+' . (b - e)
> endif
>
> call feedkeys(':' . range, 'n')
> endfunction
>
> If I start on the first line of the function, that is, "function!..."
> and press g: followed by / and then searching for "endf" and pressing
> enter, my command line will be
>
> :.,+12
>
> However, endfunction is actually on the thirteenth line after
> function!, so the range should really be .,+13. If i instead search
> for "ndf" I get the correct result.
>
> So it seems that there's something strange going on in what line is
> being set for the ] mark when performing a search under these
> conditions, coupled with patterns that match at the very beginning of
> a line.
There are a few special ways operators handle movements. Note that the
"/" is "exclusive", which means the end position of the cursor is not
included in the operated text. When this position is at the start of
the line, that line is not included. It's like the cursor ends up just
after the end of the previous line. Try it with "d/pat". This is
to make it Vi compatible. And mostly it does what you expect.
--
Place mark here ->[ ]<- if you want a dirty monitor.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: weird up/down arrows behaviour on braces 7.1.87
Yakov Lerner wrote:
> I get weird up/down behaviour when cursor traverses the braces. vim 7.1.87,
> no custom plugins. This is apparently somehow related to matchparen.
>
> The testfile is x.c below.
> Here is what happens if I press down starting from the beginning of file,
> position 1:
>
> 1. Down. instead of going to line 2, cursor shows at line 4 !!!
> 2. Down. cursor is at line 3
> 3. Down. cursor is at line 2 !!!
> 4. Down. cursor is at line 5
> 6. Up. Cursor is at line 2!!!
> 7. Up. Cursor is at line 3.
> 8. Up. Cursor is '}' line 4!!!
> 9. Up. Cursor is at line 1.
>
> --- x.c
> int foo()
> {
> return 0;
> }
> /* */
How can you tell where the cursor is and it's not the highlighting that
makes you think the cursor is somewhere else? Try using a different
color scheme.
I don't have a vt220 so I can't try it out. I wonder if you are
actually using a vt220 anyway, these are quite rare these days...
--
hundred-and-one symptoms of being an internet addict:
255. You work for a newspaper and your editor asks you to write an
article about Internet addiction...in the "first person."
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Feature request... non-uniform tabstops
On Mon, Aug 27, 2007 at 10:27:02AM -0700, Mark Waggoner wrote: > I've asked Bram in the past whether he would add this to the voting list. > The best I've been able to get is "I'll think about it" :) Perhaps if I > throw the idea out to the mailing lists I can garner a little support. > > When editing or viewing text files that contain data with fields > separated by tab characters, I would like to be able to set non-uniform > tabstops. This would allow the text to be viewed and edited in a much > more readable/understandable format than fixed tabstops can provide. > The usage model I envision is: > > set tabstop=8,10,4,20,8 > > This would make (depending on how you are counting) the first tabstop at > character 9, the second at character 19, the third at 23, the fourth at > 43, and the fifth at 51. Tabstops beyond those explicitly specified > would repeat the last tabstop, making the setting backward compatible > with what we have today, where only one value is allowed and it is used > for all the tabstops. > > Anyone else care to join me in voting to add this to the voting options? I like it a lot. I usually wind up just making the window huge and making the tabstops extra big, but variable width would be nice. > Mark Waggoner --Greg --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Feature request... non-uniform tabstops
I've asked Bram in the past whether he would add this to the voting list. The best I've been able to get is "I'll think about it" :) Perhaps if I throw the idea out to the mailing lists I can garner a little support. When editing or viewing text files that contain data with fields separated by tab characters, I would like to be able to set non-uniform tabstops. This would allow the text to be viewed and edited in a much more readable/understandable format than fixed tabstops can provide. The usage model I envision is: set tabstop=8,10,4,20,8 This would make (depending on how you are counting) the first tabstop at character 9, the second at character 19, the third at 23, the fourth at 43, and the fifth at 51. Tabstops beyond those explicitly specified would repeat the last tabstop, making the setting backward compatible with what we have today, where only one value is allowed and it is used for all the tabstops. Anyone else care to join me in voting to add this to the voting options? Mark Waggoner (I'm trying out mailing to the list with gmail for the first time. If this ends up "ugly", my apologies.) --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Possible bug in 'operatorfunc', g@, and / combination
I have the following function and binding:
noremap g: :set operatorfunc=get_command_mode_rangeg@
function! s:get_command_mode_range(type)
let b = line("'[")
let e = line("']")
if b < e
let range = '.,+' . (e - b)
elseif b == e
let range = '.'
else
let range = '.,+' . (b - e)
endif
call feedkeys(':' . range, 'n')
endfunction
If I start on the first line of the function, that is, "function!..."
and press g: followed by / and then searching for "endf" and pressing
enter, my command line will be
:.,+12
However, endfunction is actually on the thirteenth line after
function!, so the range should really be .,+13. If i instead search
for "ndf" I get the correct result.
So it seems that there's something strange going on in what line is
being set for the ] mark when performing a search under these
conditions, coupled with patterns that match at the very beginning of
a line.
nikolai
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: weird up/down arrows behaviour on braces 7.1.87
On 8/27/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
>
> On 8/27/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> >
> > I get weird up/down behaviour when cursor traverses the braces. vim
> > 7.1.87,
> > no custom plugins. This is apparently somehow related to matchparen.
> >
> > The testfile is x.c below.
> > Here is what happens if I press down starting from the beginning of
> > file, position 1:
> >
> > 1. Down. instead of going to line 2, cursor shows at line 4 !!!
> > 2. Down. cursor is at line 3
> > 3. Down. cursor is at line 2 !!!
> > 4. Down. cursor is at line 5
> > 6. Up. Cursor is at line 2!!!
> > 7. Up. Cursor is at line 3.
> > 8. Up. Cursor is '}' line 4!!!
> > 9. Up. Cursor is at line 1.
> >
> > --- x.c
> > int foo()
> > {
> > return 0;
> > }
> > /* */
> >
> >
> > Yakov
>
>
>
> The problem is related to TERM set to vt200 and it being black-and-white,
> and syntax off.
> When TERM is xterm and color, everything is fine, problem does not appear.
I played with .vimrc to find out what is needed to reproduce it.
The combination of conditions is:
- .vimrc is present but empty
- TERM set to vt220 ( black-and-white )
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: weird up/down arrows behaviour on braces 7.1.87
Yakov Lerner wrote:
> I get weird up/down behaviour when cursor traverses the braces. vim 7.1.87,
> no custom plugins. This is apparently somehow related to matchparen.
>
> The testfile is x.c below.
> Here is what happens if I press down starting from the beginning of
> file, position 1:
>
> 1. Down. instead of going to line 2, cursor shows at line 4 !!!
> 2. Down. cursor is at line 3
> 3. Down. cursor is at line 2 !!!
> 4. Down. cursor is at line 5
> 6. Up. Cursor is at line 2!!!
> 7. Up. Cursor is at line 3.
> 8. Up. Cursor is '}' line 4!!!
> 9. Up. Cursor is at line 1.
>
> --- x.c
> int foo()
> {
> return 0;
> }
> /* */
>
>
> Yakov
GUI or console? Any colorscheme? Also with
vim -u /usr/local/share/vim/vim71/vimrc_example.vim -N x.c
(Unix) or
gvim -u C:\PROGRA~1\vim\vim71\vimrc_example.vim -N x.c
(Windows) ?
Best regards,
Tony.
--
George Orwell was an optimist.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: win32 vim and file mode in CYGWIN
Tony Mechelynck wrote: > Frodak Baksik wrote: >> On 8/24/07, Tony Mechelynck <[EMAIL PROTECTED]> wrote: >>> Sorry if you see this twice: after more than 3 hours I'm not seeing it (nor >>> any reply to it) on the group. >>> >>> Frodak Baksik wrote: >>> [...] These types of issues have been discussed before on the Cygwin mailing list. Essentially the issue is with win32 vim only using the default file permissions (i.e. Inherit permissions from parent) when writing the updated file. For the behavior you desire win32 vim would need to be updated to track the actual NTFS permissions and restore them when using :write. -- Frodak >>> Does >>> >>> :set backupcopy >>> >>> improve the results? >>> >>> >>> Best regards, >>> Tony. >>> -- >>> "If you ever want to get anywhere in politics, my boy, you're going to >>> have to get a toehold in the public eye." >>> >> I checked that backupcopy=auto. >> >> The issue seems to be with the swap file. If I open a file with win32 >> vim, the swap file gets created with the default permissions. Then >> when I write the file, the backup copy has the original permissions >> but the new file has the default permissions. >> >> When I tried this scenario with Windows Word, its swap file has the >> default permissions, but when the file is saved and word is closed the >> original permissions are retained. I also tried it with notepad, >> wordpad, and visual studio. >> >> Would this be considered a bug with win32 vim on NTFS or is their >> another setting to try? >> >> Thanks, >> Frodak > > Try ":set backupcopy=yes", which is the Unix default and ought to work well > in > Cygwin, which is a Unix-like environment. > > This ought to give default permissions to the backup and keep the file's > original permissions intact. If, in addition, you have, for example, > > :set nobackup writebackup > > the backup file won't have a very long lifespan, unless there is a problem. Thanks! It worked! Of course my main development env. is CYGWIN, but a application which I have to use conflicts with CYGWIN. While I use that program and have to modify/build a project (sources), I had to use win32 VIM. And it gave me a headache because of file mode changes. Regards, namsh --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: weird up/down arrows behaviour on braces 7.1.87
On 8/27/07, Yakov Lerner <[EMAIL PROTECTED]> wrote:
>
> I get weird up/down behaviour when cursor traverses the braces. vim 7.1.87
> ,
> no custom plugins. This is apparently somehow related to matchparen.
>
> The testfile is x.c below.
> Here is what happens if I press down starting from the beginning of file,
> position 1:
>
> 1. Down. instead of going to line 2, cursor shows at line 4 !!!
> 2. Down. cursor is at line 3
> 3. Down. cursor is at line 2 !!!
> 4. Down. cursor is at line 5
> 6. Up. Cursor is at line 2!!!
> 7. Up. Cursor is at line 3.
> 8. Up. Cursor is '}' line 4!!!
> 9. Up. Cursor is at line 1.
>
> --- x.c
> int foo()
> {
> return 0;
> }
> /* */
>
>
> Yakov
The problem is related to TERM set to vt200 and it being black-and-white,
and syntax off.
When TERM is xterm and color, everything is fine, problem does not appear.
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
weird up/down arrows behaviour on braces 7.1.87
I get weird up/down behaviour when cursor traverses the braces. vim 7.1.87,
no custom plugins. This is apparently somehow related to matchparen.
The testfile is x.c below.
Here is what happens if I press down starting from the beginning of file,
position 1:
1. Down. instead of going to line 2, cursor shows at line 4 !!!
2. Down. cursor is at line 3
3. Down. cursor is at line 2 !!!
4. Down. cursor is at line 5
6. Up. Cursor is at line 2!!!
7. Up. Cursor is at line 3.
8. Up. Cursor is '}' line 4!!!
9. Up. Cursor is at line 1.
--- x.c
int foo()
{
return 0;
}
/* */
Yakov
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
RE: Make clean does not remove if_perl.c
> > On 8/25/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > > > > > Suresh Govindachar wrote: > > > > > make -f Make_ming.mak clean > > > > > > does not remove if_perl.c > > > > You are supposed to use: > > > > make -f Make_ming.mak -D PERL clean > > > > You also need to add the choices for GUI or not and debugging or not, > > otherwise the object files are not deleted or the wrong ones are > > deleted. It's a bit confusing. > > I think we should support off-directory build. It's really a pain for > me. > > By the way, do we have any plan of switching to CMake? I suggest to be very careful with changes like this. Make is everywhere by cmake is not. If people have to install cmake to be able to compile vim, that's just more troubles. Moreover it may not be available on all platforms vim is supported. It may be wiser to think of improving builds within the current environment. ---Zdenek smime.p7s Description: S/MIME cryptographic signature
