.h:4076: undefined reference to `find_win_for_buf'
collect2: error: ld returned 1 exit status
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply belo
On 11 June 2013 15:09, Chris Sutcliffe wrote:
> On 11 June 2013 13:54, Bram Moolenaar wrote:
>> Patch 7.3.1167
>> Problem:Python configure check doesn't reject Python 2 when requesting
>> Python 3. Some systems need -pthreads instead of -pthread.
&
On 11 June 2013 13:54, Bram Moolenaar wrote:
> Patch 7.3.1167
> Problem:Python configure check doesn't reject Python 2 when requesting
> Python 3. Some systems need -pthreads instead of -pthread.
FWIW, Cygwin also needs -pthreads as opposed to -pthread.
Chris
--
C
On 5 June 2013 05:29, Ron Aaron wrote:
> In file included from regexp.c:7875:0:
> regexp_nfa.c: In function ‘nfa_regatom’:
> regexp_nfa.c:983:5: error: ‘e_missing_sb’ undeclared (first use in this
> function)
Same error, building on Cygwin.
Chris
--
Chris Sutcliffe
http://emerg
=0x0500
in both cases gvim worked as expected (including the find and replace
dialogues).
So I think setting WINVER to 0x0500 in Make_ming.mak is safe.
Cheers,
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
--
You received this message from the "
e a large uncertainty about
> what the side effects are.
One of the side affects of using a function this is only available in
XP and above is that Vim will no longer work on Win2K.
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
--
You receiv
le WINVER is defined as:
# Set the default $(WINVER) to make it work with pre-Win2k
ifndef WINVER
WINVER = 0x0400
endif
So adjusting it in the source would be ineffective anyway, you should
just adjust WINVER in Make_ming.mak.
Cheers,
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http
ink.sh: Linking failed
> make[1]: *** [vim] Error 1
> make[1]: Leaving directory `/home/inkarkat/swdev/vim/vim/src'
> make: *** [first] Error 2
Having the same issue with Cygwin.
$ python --version
Python 2.6.8
$ uname -a
CYGWIN_NT-6.1 BMOTEC3017201LT 1.7.15(0.260/5/3) 2012-05-09 1
Hi Bram,
On 15 April 2011 15:00, Bram Moolenaar wrote:
> It's easy enough to add "mksh" and "pdksh" next to "ksh" in src/option.c
Agreed, attached please find a patch that addresses the issue.
Thank you,
Chris
--
Chris Sutcliffe
http://emergedesk
On 14 April 2011 20:11, Chris Sutcliffe wrote:
> On 14 April 2011 16:38, Chris Sutcliffe wrote:
>> I've noticed an issue with vim while running under mksh and pdksh.
>> Specifically, the stderr output by gcc (i.e. compilation warnings and
>> errors) is not captured in t
On 14 April 2011 16:38, Chris Sutcliffe wrote:
> I've noticed an issue with vim while running under mksh and pdksh.
> Specifically, the stderr output by gcc (i.e. compilation warnings and
> errors) is not captured in the QuickFix window. I see the stderr
> output in the terminal
n vim returns to the editor window and I execute a :cl or :copen, I
only see stdout output.
Any help would be greatly appreciated, thank you.
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
--
You received this message from the "vim_dev" maillist.
On 11/01/2011 12:34 AM, James Vega wrote:
To expand on ZyX's response, you would want to use ":tab split +bn"
for the
behavior you want.
If you want to specify a buffer number:
:tab sb [buffer number]
Chris
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your
On 21 October 2010 09:07, Christian Brabandt wrote:
> On Thu, October 21, 2010 2:36 pm, Chris Sutcliffe wrote:
>> To that end, this minor patch populates v:windowid with the gvim HWND
>> under windows:
> [...]
>
> What can that be used for?
A quick way to retrieve th
On 21 October 2010 07:00, Chris Sutcliffe wrote:
> On 20 October 2010 15:24, Kana Natsuno wrote:
>> On Thu, 21 Oct 2010 02:18:08 +0900, Bram Moolenaar wrote:
>>> Patch 7.3.031
>>> Problem: Can't pass the X window ID to another application.
>>> Solution:
windowid" etc to express that it's not
> related to "window" (as a viewport on a buffer), shouldn't it?
What would be cool would be to v:windowid to return the gvim HWND in
the Windows world. At which point v:windowid would be appropriate
across OSes.
Chris
--
Chris Su
On 27/08/2010 8:37 PM, Charles E Campbell Jr wrote:
Charles E Campbell Jr wrote:
Hello!
I usually build vim myself with cygwin + make -f make_cyg.mak .
However, I'm getting a message
gcc: The -mno_cygwin flag has been removed; use a mingw targeted
cross-compiler.
You need the MinGW comp
iles/ into vim73 home dir
> or do some other trick to make different version shared with the same
> script/conf files.
Using my self compiled version of vim73d (latest hg update):
vim: C:\Program Files\Vim
vim runtime: C:\Program Files\Vim\vim73d
which is consistent with previous
On 8/02/10 6:28 AM, Bram Moolenaar wrote:
I don't think this depends on the OS but on the compiler. I'm building
Vim fine on Windows XP. That is with MSVC 2010.
We could solve this with a few #ifdefs, I suppose. But it will mean
that the binary you build with older MSVC won't install/uninstal
On 8/01/10 7:46 PM, Christian J. Robinson wrote:
Oops, the subject should have been uninstal.c, not gvimext.dll
The problem is that WINVER is defined as 0x0400 in Make_ming.mak and
RegKeyDeleteEx is only available with WINVER 0x0502 and above.
Chris
--
You received this message from the "v
On 7/21/10 3:57 PM, Chris Sutcliffe wrote:
GVim fails to compile with revision 2368:435b5c6a5191 under MinGW:
It turns out this was the result of an incorrect patch to w32api that I
was testing. Once removing the incorrect patch GVim compiles as expected.
Sorry for the noise.
Chris
--
You
UnRegisterTypeLib(_GUID*, WORD, WORD, LCID,
SYSKIND)'
if_ole.cpp: In function 'void GUIDtochar(const GUID&, char*, int)':
if_ole.cpp:638:33: error: cannot convert 'const GUID' to 'CLSID*' for
argument '1' to 'HRESULT StringFromCLSID(CLSID*, WCHAR
runtime files now version
specific?
Thank you,
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information,
ecover the file, or is the
contents lost?
Thank you,
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
On 18 May 2010 16:29, Bram Moolenaar wrote:
>
> Strange that these compilers don't define uint32_t. I'll add it in
> vim.h:
Unfortunately revision 2184 seems to have broken Cygwin compilation
with complaints of uint32_t being undefined.
Chris
--
Chris Sutcliffe
http://eme
als.h.
There is a little bit of an issue with this in the vim73 branch (at
least for Cygwin). In particular:
src/sha256.c (line 19):
typedef unsigned long uint32_t;
This definition conflicts stdint.h:
typedef unsigned int uint32_t;
Perhaps rename uint32_t to ulong32_t?
Chris
--
Ch
oblem with a
> 64-bits integer type declaration.
>
> Can you send me the last version, please?
If you could send it to the list it would be greatly appreciated,
since I would like to test it with MinGW.
Thank you,
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.
gwin. I am not sure all
> users upgraded to 1.7 already.
It actually would require a current gcc/g++, not specifically Cygwin
1.7. The final gcc / g++ release for 1.5 also made this
differentiation.
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
--
Yo
to collapse (which didn't happen before).
Chris
--
Chris Sutcliffe
http://emergedesktop.org
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
au BufWritePost * if &ft == 'cpp' | silent execute '!ctags *' | endif
Which works in similar fashion but doesn't cause the undesired fold collapsing.
Chris
--
Chris Sutcliffe
http://emergedesktop.org
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
line:
au BufWritePost * nested filetype detect
Which I use to re-read the ctags file so that Omni-complete has the
latest information after a file is written. This worked without issue
prior to this patch. Is there an alternate implementation I could use
that would play nicely wit
> I can't reproduce the problem. Do you know the exact steps I have to
> take to do it?
I can reproduce it by editing a cpp file with foldmethod=syntax,
typing 'zO' to open a fold, go in to the previously folded function
and type ':w' and the fold is closed.
patch may have caused an undesired side affect, in that
if I save a file (:w) with foldmethod set to 'syntax', the fold closes
on the line that I was editing.
Chris
--
Chris Sutcliffe
http://emergedesktop.org
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Is it possible to configure vim in such a way as to not needing to be
built in the /vim/src directory? I'd like to use the same source
repository to build vim and gvim for Cygwin and MinGW and the target
names conflict if both build in the /vim/src directory.
Thank you,
Chris
--
Only Bram can say for certain, but I suspect that the patches will be
available as they are today, via individual files on the FTP servers.
I believe the intent is to have all development centralize on
Mercurial as opposed to maintaining CVS and SVN.
Chris
--
Chris Sutcliffe
http://emergedesktop.o
nyway, aren't they?
Chris
--
Chris Sutcliffe
http://emergedesktop.org
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
> In the meantime, will you be updating the Mercurial repository as well
> as CVS? I've noticed patch 328 is not in Mercurial yet, so I'm just
> curious (I apologize if I'm jumping the gun a little bit here).
It's there now...
Thank you!
Chris
--
Chris Sutcl
y when 7.3 comes
> out (whenever that will be).
In the meantime, will you be updating the Mercurial repository as well
as CVS? I've noticed patch 328 is not in Mercurial yet, so I'm just
curious (I apologize if I'm jumping the gun a little bit here).
Cheers!
Chris
--
Chris Su
r of a more modern DVCS.
Chris
--
Chris Sutcliffe
http://emergedesktop.org
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
his Mercurial repository to be the
'main' repository for Vim (like CVS is today)?
Chris
--
Chris Sutcliffe
http://emergedesktop.org
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
n CVS, was it missed?
Chris
--
Chris Sutcliffe
http://emergedesktop.org
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
> This un-hardcoding is part of my patch for cross-compiling with mingw
> from 2009-03-18, which is still on the todo list.
Ah, excellent! I'll just have to sit tight and wait for your patch to
make it in to an official patch.
Cheers!
Chris
--
Chris Sutcliffe
http://emerge
The compiler is currently hard coded to use gcc in xxd/Make_cyg.mak,
the attached patch allows it to be overridden using the standard
'CC=' mechanism.
Chris
--
Chris Sutcliffe
http://emergedesktop.org
--~--~-~--~~~---~--~~
You received this messag
r_u*p;
> int retval = OK;
> + #ifdef __CYGWIN__
> + char_uposix_fname[MAX_PATH];
> + #endif
> +
MAX_PATH is undeclared when I attempted to compile this with Cygwin.
I changed it to MAXPATHL and it works fine.
Chris
--
Chri
ime error :
>>
>> Error E2451 .\ex_getln.c 3716: Undefined symbol 'p' in function
>> vim_strsave_fnaeescape
>> *** 1 errors in Compile ***
>
> I see this with Cygwin make as well.
MinGW also suffers from this.
Chris
--
Chris Sutcliffe
http://emergedesktop.org
cp gvimtutor /usr/bin/gvimtutor
cp: cannot stat `gvimtutor': No such file or directory
make[1]: *** [installtutorbin] Error 1
make[1]: Leaving directory `/usr/src/vim/vim7/src'
make: *** [install] Error 2
Chris
--
Chris Sutcliffe
ht
-cygwin' switch, which in
the background actually invokes the MinGW gcc that's installed when
ever you install the cygwin gcc. That's why __MINGW32__ is defined.
Cheers!
Chris
--
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org
#x27;ve made those changes.
Cheers!
Chris
--
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Sending to the list... darn gmail keeps wanting to respond to the
original sender...
-- Forwarded message --
From: Chris Sutcliffe <[EMAIL PROTECTED]>
Date: Sep 28, 2007 3:57 PM
Subject: Re: patch 7.1.123
To: Bram Moolenaar <[EMAIL PROTECTED]>
> I don
d
C:\Cygwin\home. This allows for a common vim user configuration
environment in both environments.
Cheers!
Chris
--
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org
--~--~-~--~~~---~--~~
You received thi
> Though I think it may have created another. In my .vimrc I have:
>
> set runtimepath=$VIMRUNTIME,~/vimfiles
>
> which no longer loads any of the scripts from my ~/vimfiles directory.
I'm running on Windows XP Pro, with gVim compiled via MinGW.
Chris
--
he problem. Thanks!
Though I think it may have created another. In my .vimrc I have:
set runtimepath=$VIMRUNTIME,~/vimfiles
which no longer loads any of the scripts from my ~/vimfiles directory.
Chris
--
Chris Sutcliffe
http://ir0nh34d.googlepages.c
Replied direct to Bram instead of the list...
On 8/15/07, Chris Sutcliffe wrote:
> > Adding (char *) casts for things that are already character strings?
> > Isn't this a problem in gcc?
>
> GCC complains that const char*'s is being passed as a char*'s (beca
*)&dyn_libintl_textdomain},
+ {(char*)"bindtextdomain", (FARPROC*)&dyn_libintl_bindtextdomain},
{NULL, NULL}
};
@@ -835,7 +835,7 @@
(LPTSTR)location) > (HINSTANCE)32)
return location;
}
-return "&
__IID_DEFINED__), I've added an extra check to
essentially accomplish what the Makefile was previously doing with the
-D__IID_DEFINED__ option for previous versions of the w32api.
Cheers!
Chris
--
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.
Should have replied to the list...
On 8/9/07, Chris Sutcliffe <[EMAIL PROTECTED]> wrote:
> Hey Bram,
>
> > We need someone with the slightly older MingW to try it out...
>
> I reverted to the previous w32api version (3.9) which does not
> explicitly define __IID_DEFIN
$(CC) $(CFLAGS) -c -o $(OUTDIR)/if_ole.o if_ole.cpp
Cheers!
Chris
--
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more in
sor. (Chris Lubinski)
> Files: runtime/plugin/matchparen.vim
I've rsync'd against ftp.nluug.nl and it doesn't contain this change.
Going forward, is the runtime directory in CVS / SVN the definitive
source for the latest runtime files?
Thanx!
Chris
--
Chris Sutcliff
Is this not the case
anymore?
Cheers!
Chris
--
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
his update been committed to CVS?
Chris
--
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
60 matches
Mail list logo
