Yukihiro-san,
I gave up on catching up Racket updates in if_mzscheme so the interface has
been broken for some time now. Your patch seems to finally fix the issues I
encounterred (tested on Arch successfully), many thanks for that.
>> With this change, test70 still fails because test70 uses
Bruno Sutic wrote:
It's possible to use a local Mercurial repository with Github, right?
So the instructions on how to get Vim would only need to change the URL.
Github unfortunately does not have support for Mercurial repos.
However, it is possible to use Mercurial locally and push to
Currently the 'lispwords' setting is global, yet three filetypes attempt
to change it on filetype/indent load: scheme, clojure, and art.
Scheme and Clojure, in particular, are two very different Lisp variants,
but both modify 'lispwords' to influence their indenting. Both filetypes
also call
I'm trying to build vim 7.4.178 with +mzscheme and racket 5.93-1 on
archlinux, but it fails :
# error MzScheme =4 must include mzscheme_base.c, for MinGW32 you need
to define MZSCHEME_GENERATE_BASE=yes
^
Patch below fixes this issue (execute make autoconf to regenerate
configure).
Make sure you have a recent version of the source and clean up before you
build.
Thanks, there really is no need to waste time teaching me how to build Vim.
Anyway I found the cause: it is Python that is broken, not Vim. If Python3
is installed properly (as opposed to python3X.dll simply
Hi,
Apparently it's not only I who can't get Python3 support working in Windows
(at least Win7 x64), neither dynamic nor static one, and neither x86 nor
amd64. Here are options I tried:
All of these builds crash inside pythonXX.dll on py3 print(1+2):
nmake -f Make_mvc.mak FEATURES=BIG GUI=yes
The problem above only occurs at runtime using racket 5.3.2 with the
same command line.
With racket 5.3.3 it works fine.
Works fine for me. Did you delete mzscheme_base.c and *.o files before
building Vim with another version of MzScheme?
--
--
You received this message from the vim_dev
but vim with racket 4.2.3 doesn't compile with DYNAMIC_MZSCHEME=yes
anymore.
As I wrote previously, if you want DYNAMIC_MZSCHEME, you need to either
use version 3.x or build Racket yourself with conservative GC.
--
--
You received this message from the vim_dev maillist.
Do not top-post!
I'm using MinGW with gcc-4.6.2, Racket 4.2.5 and
MZSCHEME=c:/plt
MZSCHEME_VER=3m_6ncd1k
DYNAMIC_MZSCHEME=yes
MZSCHEME_GENERATE_BASE=yes
and the command line is:
make -f Make_ming.mak
Ok, I encounterred another problem with 4.2.5: Vim compiled fine but failed
to link with undefined
I built vim with racket 5.3.2 (with racket 4.2.5 is not possible) using
MinGW on Windows 7, 64-bit and whenever I run, say ':mzscheme 5' a
windows pops up with the message:
Your command line to build?
Works fine with Racket 5.3.3
mingw32-make -f Make_ming.mak GUI=yes CSCOPE=yes
On Sat, Feb 9, 2013 at 12:36 AM, Cesar Romani cesar.rom...@gmail.comwrote:
I'm building vim on Windows 7 with MinGW.
It cannot be compiled with racket 4.2 anymore.
Racket 4.2.3 works fine for me with gcc-3.4.5 and 4.5.2. Tried both 3m and
conservative GC versions.
If you want it fixed please
Bram,
Test 70 fails. I worked around it for now by changing:
:if l2[2] == l2
to
:if l2[2] == item2
This was caused by a part of patch from Eric Dobson. I restricted the scope
of this change to Mac only and test 70 has passed on Linux and Windows.
Please find the patch
It also doesn't work on Windows by building with MinGW.
I always get:
[...]
... -freg-struct-return -s -DINCLUDE_MZSCHEME_BASE if_mzsch.c -o
gobjZi386/if_mzsch.o
if_mzsch.c: In function 'window_new':
if_mzsch.c:1747:21: error: lvalue required as left operand of assignment
if_mzsch.c: In
Test 70 fails. I worked around it for now by changing:
:if l2[2] == l2
to
:if l2[2] == item2
Please find out what the proper solution is.
Thanks Bram. Will check it out.
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below
Hi Bram
On Wed, Jan 23, 2013 at 5:12 PM, Bram Moolenaar b...@moolenaar.net wrote:
You sent me a patch two months ago. Did you make an update since then?
Please send me the patch again to make sure it works with the current
source code.
Here is an updated patch. As of another issue with
Eric,
I incorporated you changes into
http://code.google.com/r/sergeykhorev-vim-mzscheme/source. Can you try it
on Mac?
Bram,
Please let me know what I should include in the distribution. The patch
was missing changes to configure.in.
I will send you a cumulative patch once it is tested.
Looks good except one thing: you really wouldn't want to gc environment
(see MZ_GC_CHECK) before registering it with MZ_REGISTER_STATIC.
BTW are there any guarantees that MZ_REGISTER_STATIC doesn't trigger
garbage collection?
@@ -861,6 +865,12 @@
scheme_set_stack_base(stack_base, 1);
On Fri, Dec 14, 2012 at 9:20 AM, Eric Dobson eric.n.dob...@gmail.comwrote:
I figured this out. It was that vim was not being compiled with the
precise garbage collection when racket was, and a couple of bugs on the vim
allocation of racket objects. I'll hopefully have a patch soon.
Are you
I have recently installed a version of vim with the mzscheme option enabled.
And it sortof works except that some times it segfaults or has other memory
corruption issues. So I enabled MZ_GC_CHECK when compiling vim, and now I
get the corruption every single time on startup.
I have no access
Thanks, it works but you need to have libracket3m_8bh220.dll on your
path.
That's correct. Racket 5.x dlls cannot be loaded dynamically. You need
version 4.x (or earlier) built with conservative garbage collector
(CGC)
--
You received this message from the vim_dev maillist.
Do not top-post!
if_mzsch.c:848:4: error: #error Precise GC v.4+ or Racket with
futures/places do not support dynamic MzScheme
Default Racket garbage collector (3m) doesn't support dynamic loading
of dlls. For your reference this is how I build Vim with the latest
Racket.
mingw32-make -f Make_ming.mak GUI=yes
I'm building vim 7.3.744 on Windows 7 with MinGW. By compiling it with
Racket 5.3.1 I get:
My comment about Make_cyg applies to Make_ming as well. You need to
patch a Racket header file and use my patch for Vim.
--
You received this message from the vim_dev maillist.
Do not top-post! Type
No, the directory is /share/collects. Configure doesn't find it. I
have changed configure.in and now it seems to work. I'll do some more
checks and send out the patch.
Thanks. Your variant worked for me as well.
--
You received this message from the vim_dev maillist.
Do not top-post! Type
Yes, autoconf has run. As I said, I don't see MZSCHEME_GENERATE_BASE
defined in the configure script anywhere.
I tested this on a fresh install of Ubuntu 12.10.
Speaking of the error message, it specifically refers to MinGW because
I wasn't able to write anything more or less automatic
Sergey, are you testing this on Racket-5 (5.3 series, 5.3.1 November 2012)?
Hi Tim, most of the time I tested it with 5.2.1 but did some checks on
5.3.1 too.
--
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
Hi,
I have a problem building with the MzScheme interface on a newly updated
Ubuntu 12.10 system. The errors are:
/home/mool/vim/vim73/src/if_mzsch.c|632 col 3| error: #error MzScheme 4.x
must include mzscheme_base.c, for MinGW32 you need to define
MZSCHEME_GENERATE_BASE=yes
||
Yes, autoconf has run. As I said, I don't see MZSCHEME_GENERATE_BASE
defined in the configure script anywhere.
I tested this on a fresh install of Ubuntu 12.10.
Speaking of the error message, it specifically refers to MinGW because
I wasn't able to write anything more or less automatic for
Thanks, reporting vim.org problems here is good, or direct to
Bram, or direct to me and I will arrange with Bram.
Speaking of the site, does it also make sense to remove tip search in Search
for Vim Tips section? Probably a link to the wiki would be enough.
--
You received this message
and
compatibility macros allow to use older versions of MzScheme.
Previously we used macros that made new API look like an older one.
* eval function of the interface is now able to convert Vim funcrefs
into Scheme functions
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good
Hi Bram,
Patch 7.3.639
Problem:It's not easy to build Vim on Windows with XPM support.
Solution: Include the required files, they are quite small. Update the
MSVC makefile to use them. Binary files are in the next patch.
Thanks for including this. Attached are a few
.\ObjG\blowfish.obj : fatal error LNK1112: module machine type 'x64'
conflicts with target machine typ
e 'X86'
NMAKE : fatal error U1077: 'c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\BIN\x86_amd64\link
.EXE' : return code '0x458'
Apparently the linker tries using x86 binaries.
Thanks for making this available. It's fairly small and a quick glance
shows the license is liberal, so perhaps we should simply include it in
the distribution. Otherwise I can put it on the Vim ftp site.
I think it's a good idea to include it into the distribution.
--
You received this
Apparently the linker tries using x86 binaries. The simplest solution
would be delete ObjG directory and build from scratch.
Thanks,
I just tried that but the result is exactly the same. It compiles all
the files correctly but linking gives the same error as before.
Can you remove ObjG
link /RELEASE /nologo /subsystem:windows /LTCG:STATUS
...
advapi32.lib shell32.lib /machine:i386 /no
Ok, the problem is in /machine:i386 which should be AMD64 for x64
builds. Either something is wrong with your environment or
Make_mvc.mak failed to detect the target architecture
Hi Bram,
Note that depending on the license the source files need to be included
as well. At least include a README that mentions the copyright.
I am travelling now and don't have 64bit compiler on my laptop. Will
prepare the zip when I'm back (in 2 weeks).
Here is the zip containing the
Hi Bram,
I would prefer for people to be able to easily download and install the
dependencies. It's difficult enough to build Vim already.
Perhaps you can make one zip file that contains the required header
files and the .lib files for 32 and 64 bit?
Note that depending on the license the
# XPM - Include support for XPM signs
# You need to download or build xpm.lib somehow.
# You can get the most recent version of libXpm-*.zip from
# http://cgit.freedesktop.org/xorg/lib/libXpm
But that site is down. I found an alternate xpm_w32 zip file on
ftp.gnu.org, but it does not
It does not compile though. It says it can't find xpm.h although the
directory is correctly added per -I parametert.
You didn't mention how you tried to build Vim, here is how I did it:
nmake -f Make_mvc.mak GUI=yes CSCOPE=yes NETBEANS=yes XPM=e:\hg\xpm
E:\HG\vim\srcdir /B /S e:\hg\xpm
Thanks. I tried and it builds with MSVC 2008. Don't know how to try if
it actually works.
Originally I did it for that Netbeans plugin which for some reason
used only XPM icons. Commands below will show whether XPM lib is
working or not:
:exe 'sign define vimxpm
if_mzsch.c:806:4: error: #error Precise GC v.4+ or Racket with
futures/places do not support dynamic MzScheme
make: *** [gobjZ/if_mzsch.o] Error 1
The only changes I did on Make_ming.mak are:
MZSCHEME=c:/Racket
MZSCHEME_VER=3m_8avmg8
Also you
StatusLine HighLighting is only working when the window is split
An obvious question: have you tried this on other platforms including
different versions of X server and Motif?
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are
Thanks for the patch. I have been unable to reproduce the crash, I hope
someone can verify this patch fixes the problem.
Have you added autocmd
VimEnter,BufNew,BufEnter,BufWritePost,VimResized * redraw? It is an
essential part.
I do wonder how row can be too big, perhaps there is a problem
my repro step:
1. run gvim
2. open NERDTree windows
3. create several tabs using 't' shortcut of NERDTree plugin
4. '1gt'
5, maximize gvim
6, '2gt'
7, restore the windows size from maximize window to normal window.
8, '1gt'
Result: after 8th step, my gvim will crash definitely.
My take
Bram has included the changes in Scheme runtime files, the are
available in Mercurial now.
--
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
for improvement feel free to provide a
patch. I am sending updated file with did_ftplugin to Bram.
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply
I am sending updated file with did_ftplugin to Bram.
To make things clear.
While I believe Scheme is a Lisp dialect (both R5RS and R6RS say so
too), runtime! ftplugin/lisp.vim ftplugin/lisp_*.vim
ftplugin/lisp/*.vim seem to be unnecessary here so my update just
copies all code from
I'd like to try to join the development effort of the VIM. I am experienced
embedded developer.
Do you have some getting started guide for this case or some bugs to fix?
Thanks a lot,
--- KostaZ
You might want to do :help todo and pick your favourite bug(s) :)
--
You received this message
Off the top of my head, there are some entities initialiased in (the old)
main(), which are then exported to scheme. My split point seemed to capture
them once they were ready.
There is no need to export them explicitly: they are added on the
first call to the MzScheme interface. The only
Ok, calling main recursively is a smart move... except Windows GUI
does not use main but I'll fix that ;)
I am going to clean this up a bit and remove dynamic MzScheme
altogether (it's not working properly since version 4.x)
--
You received this message from the vim_dev maillist.
Do not
I am going to clean this up a bit and remove dynamic MzScheme
altogether (it's not working properly since version 4.x)
On the second thought I decided to keep dynamic MzScheme for now.
Tim, I slightly reworked your patch (I am not sure all compilers like
calling main the second time), also I
Looks interesting. Trampolining main at the very top is much earlier
than I dared!
But that's probably me being too conservative.
I look forward to testing it in the field!
And I'll get back to you when I have.
Actually it is too early: it worked fine on Windows but not on Linux.
So I'm
Here's the patch in a legible format:
Cool, I will play with it on the weekend.
+ * We trampoline back into main -- to avoid a complete refacator.
refacator must be an interesting concept ;)
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below
Improving stability -- the trampoline has to be split so that a
certain degree of initialisation can occur.
This has necessitated (in this iteration) that:
static char_u *fname = NULL;
static mparm_T params;
static int i;
Are all statics (is this OK -- or is there a
This causes a SEGV.
It seems to be in GC_add_roots -- but I don't know whose GC_add_roots
that is (I think my racket is actually a 3m variant)
Looks like the folks changed something in Racket... again. I will take a look.
--
You received this message from the vim_dev maillist.
Do not
guess it is now up to
Bram to decide what to do with the plugin.
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying
every time a user types a letter.
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
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
This seems to have petered out without a resolution. I believe I made
a valid point below that the documentation and the behavior of
matchparen are not in agreement. I would appreciate either
acknowledgement that it's a bug and that it's been entered into the
official bug db for future
if syntax highlighting is off.
Speaking if the bug database, there are two ones: :help todo inside
Vim and http://code.google.com/p/vim/issues/list.
Frankly I doubt that adding this to any of the databases will do any
good: there are too many real bugs in the todo list.
--
Sergey Khorev
http
According to :help Number, a Number variable is a 32-bit signed integer. No
mention of anything else.
According to :help limits, a Number variable can have an absolute value
larger than 2^31 (i.e. 2 * 1024^3) on 64-bit systems.
AFAICT, the former seems to be true: Experiments with :echo and
in the distribution. Plus one of Vim
points is to be as much vi-compatible as possible.
I assume syntax is off because not all people like Christmas tree-like
highlighliting and it may slow down editing large files.
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can
: % is implemented in nv_percent function in Vim
source and matchparen is a Vim plugin
($VIMRUNTIME/plugin/matchparen.vim) which relies on the names of
syntax highlighting groups to skip over string literals etc.
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline
Just noticed a small typo in matchparen.vim saying We match escape
for special items, such as listpEscapeSpecial.
In fact it is to match with lispEscapeSpecial. Not a big deal but
might confuse someone who wants to know what that listpEscapeSpecial
is.
--
You received this message from the
on a Slackware 13.37 64-bit system. I built vim
from source. cpoptions=aABceFs.
:ver would be more useful.
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below
/matchparen.vim and see whether it breaks anything or not.
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
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
noread_cnt = 0;
garray_T ga;
intdelay = 1;
-# ifdef FEAT_MBYTE
DWORD buffer_off = 0; /* valid bytes in buffer[] */
-# endif
SECURITY_ATTRIBUTES saAttr;
-
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody
Attached patch avoids such glob expression and should
thus be more portable. I can only test it on Linux so I would
appreciate if someone else can confirm that it fixes the bug
on Windows.
Thats looks better than my workaround. But it should be tested.
Anyone?
Works great on Windows.
--
This website redirects you to http://racket-lang.org/ now. Is it time
to update the docs? helpgrep \racket\ doesn't turn up any results.
But I assume that people have been able to compile with and use this
feature, so obviously the correct libraries are available somewhere.
It looks like
2010/12/28 Dominique Pellé dominique.pe...@gmail.com:
Using Vim-7.3.89, I see a discrepancy between between
output of :cscope help and :help cscope-find:
:cscope help
...snip...
t: Find assignments to
:help cscope-find
...snip...
4 or t: Find this text
Christian Brabandt cblists at 256bit.org writes:
I see that on Windows XP with Vim 7.2.284 after approximately 2
iterations. But what is really weird is, that the whole gui is broken
afterwards. The window is not redrawn correctly afterwards and when typing
the letters appear in the root
Works for me. Checked with VC6 which does not have the invalid param
handler. I tidied it up for potential ambiguity and reworked the patch -
see attached. Using macros for the function calls removes the needs for
duplicating the complex conditional or introducing another symbol for later
F1rst! :-)
Pros: All Windows specific code.
Cons: Can't do anything clever with an invalid format string.
Should be ok with mingw32.
Wow, so quick :)
I think you've done it right by installing the handler once and for
all. For users of ancient compilers I suggest to add something like:
#if
Is there a function to ask the system what the valid coordinates are?
Simply removing these lines will mean that resizing may result in the
gvim window being outside of the screen boundaries on a single monitor.
It seems GetSystemMetrics can do the trick (
It is by design in the recent VC CRT libraries (VS2005 onwards?) Any
unsupported format specifier will result in a crash. On Windows, or at
least builds that use recent VC CRT libraries, VIM needs to validate the
format string that it only contains supported format specifiers. I'm
guessing
when system()
function is used?
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
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
Unless you mean why it is necessary to have a DLL to perform these
operations on Windows.
Exactly
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply
processes, what's wrong with :call system(cmd
/c start notepad)?
And URLs could be opened in the same way too: :call system(cmd /c
start http://www.vim.org;)
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from
Geert,
I included in SET INCLUDE the path to my cygwin include headers that
contains inttypes.h but then I get the following error:
I'm not sure it's a good idea to mix cygwin and MSVC headers.
Correct solution would be like patch below, although I didn't test it
because Ruby wants MSVC 6.0.
nmake -f Make_mvc.mak GUI=yes MSVCVER=9.0 PYTHON=c:\Python26 RUBY=c:
\Ruby19
You also need to specify RUBY_VER_LONG and, perhaps, RUBY_PLATFORM,
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from
Hi,
I've noticed the following item in Vim TODO:
Why does this give a #705 error:
let X = function('haslocaldir')
let X = function('getcwd')
Inserting unlet X helps.
It seems this can be easily fixed with the patch below.
diff -r aab202d244b6 src/eval.c
--- a/src/eval.cWed Mar 10
at least on my computer, vim crashes when evaluating this line:
:ruby require 'e2mmap'
With ruby 1.8.7 everything is okay.
Another thing I noticed (now with ruby 1.8.7 or 1.8.6). When you try
:ruby p VIM::evaluate(input('Foo'))
And pressesc, you get an error message:
BTW since ruby 1.9 tends to break code ruby written for ruby 1.8, I
think there should be an easy way to query ruby's version number.
I am not sure I understood you correctly. Compiler detects Ruby
version at compile time already (see numerous #ifdefs in if_ruby.c).
And I do not think there is
Thanks. It works for me too (Windows XP, MSVC 7.1, Ruby 1.8.6).
Thanks for the confirmation.
--
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
Ok, here is a patch to build Vim with dynamic Ruby loading.
I've tested it with Ruby 1.8.7 and 1.9.1 from
http://rubyinstaller.org/download.html
I believe there might be other distros, so if anyone has problems with
the patch, please provide download link and command line you used to
build Vim.
Patch 7.2.363
Problem: Can't dynamically load Perl 5.10.
Solution: Add the function Perl_croak_xs_usage. (Sergey Khorev)
Files: src/if_perl.xs
I've just found the patch doesn't work with Perl 5.10.0 (but it works
for versions older than 5.10.0 and newer than it). I am not sure how
that.
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.phpdiff -r 8a0a8f10b43e src/if_perl.xs
--- src/if_perl.xs Wed Feb 03 18:14:49 2010
Long story short, your patch works fine for me too.
Cool, thank you!
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
ex_cmds2.c: In function `fopen_noinh_readbin':
ex_cmds2.c:2819: error: syntax error before numeric constant
make: *** [gobjZ/ex_cmds2.o] Error 1
Seems like a typo in ex_cmds2.c. That should fix it:
*** ../vim72.342/src/ex_cmds2.c Tue Jan 19 19:51:15 2010
--- src/ex_cmds2.c Tue Jan 19
You are right, both are mistakes. Thanks for the patch!
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
Hi,
It does that for C-], too, but as you say, it seems to do the right
thing for *. I don't know why. Maybe a bug?
Yes, for some reason Vim always escapes some special characters even
if we are not going to pass them to a shell or regexp-using command.
So :tag ident? will work but ^] on
# end of choices
###
+ !if ($(CPU) == AMD64) || ($(CPU) == IA64)
+ CFLAGS=$(CFLAGS) -DWIN64
+ !endif
+
!ifdef OS
OS_TYPE = winnt
DEL_TREE = rmdir /s /q
--
Sergey Khorev
http://sites.google.com/site/khorser
Can
not sure what's the point in knowledge what OS version
we are running.
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
the argument either way. It should obviously be consistent
with whatever win16 and win32 do, so if they're compile-time
architecture checks, all is fine.
I'm afraid you cannot load 64-bit DLL into 32-bit process even in x64
Windows. In fact, that was why I looked into has(win64)
--
Sergey Khorev
to behave like another WIN32.
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
obliterated at the last time I reworked the
interface so it should be safe to remove.
--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?
--
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org
Steve,
As a result, I'm now getting a build failure, with the following error:
\if_mzsch.c:641:3: #error MzScheme 4.x must include mzscheme_base.c, for
MinGW32 you need to define MZSCHEME_GENERATE_BAS
E=yes
make: *** [gobj/if_mzsch.o] Error 1
This is correct behaviour.
As it is
-static.zip
(I'm going to move the port to Google Code entirely)
If you are using an older version, please backup it somewhere just for
the case. Let me know if you have any problems.
--
Sergey Khorev
http://iamphet.nm.ru
Can anybody think of a good tagline I can steal
It can be downloaded from
http://cscope-win32.googlecode.com/files/cscope-15.7a-win32rev14-static.zip
(I'm going to move the port to Google Code entirely)
Found a small annoyance with Cscope using short names even for paths
without whitespaces. Fixed in
.
--
Sergey Khorev
http://iamphet.nm.ru
Can anybody think of a good tagline I can steal?
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Tony Mechelynck wrote:
Ah, I see, thanks. If I invoke cscope -b again with the same arguments,
and the database exists, will it run faster acording to which sources
have been updated and which ones haven't, as mentioned near the top of
the manpage?
Yes, it will. But I think Vim source
Hi,
It's not clear to me whether to repeat this after the sources change,
I'll have to read the cscope manpage in more detail (it seems to say
cscope is clever enough to update the database if the sources have
changed, but can I rely on that?)
No, Vim executes cscope with cscopeprg -dl
1 - 100 din 102 matches
Mail list logo
