Re: patch 7.0.198 (extra)
> Patch 7.0.198 (extra) > Problem:Win32: Compiler warnings. No need to generate gvim.exe.mnf. > Solution: Add type casts. Use "*" for processorArchitecture. (George > Reilly) > Files: src/Make_mvc.mak, src/eval.c, src/gvim.exe.mnf, src/misc2.c > This patch collides with some patches I posted earlier. I adopted my patches. They can be downloaded for a while from http://members.tcnet.ch/michaelis/vim/patches.zip With kind regards Mathias
Re: VC8 makefile patch
Hi >> Alas, your patch doesn't work on my machine for three reasons: >> >> 1) I use VCExpress version to build vim. This is VC8, but there is >>no SDK. > > I didn't think the Express version of the compilers supported optimized > code generation. And I am surprised VCExpress comes without nmake. > I don't know either if Express optimizes well -- at least it doesn't issue any warnings about unrecognised compiler options since I applied your patch. The VCExpress version have an own version of nmake. But it doesn't have an SDK. So I have to install this separately. I thought the best thing is to use a batch file located at %ProgramFiles%\Microsoft Platform SDK\SetEnv.Cmd to set up the environment, but may be I'm wrong. With this batch script first the path of the SDK is searched, and after that the path of the VCExpress tools. So the nmake of SDK is found first. >>..., but since version 7.0 of the VC toolset there >>exists a environment variable MSVCVer which IMHO should be used >>when it is defined. >> > I don't believe this is the case. For my install of VC8 there is no > MSVCVER variable defined. Could this may be a feature of VCExpress? > It's a feature of the SDK, not of the Visual Tools. MSVCVer is defined by the mentioned batch application SetEnv.Cmd. > So there are now two issues. Non-SDK build environments don't have > MSVCVER variable, while SDK build environments have version numbers that > can be out of synch with the version of Visual C. > Not exactly: The SDK script mentioned above searches for a VC environment. If it finds one, it sets the MSVCVer environment variable appropriate to the C compiler it has found. > It would be nice to keep the makefile handle its environment > automatically without developers having to define variables to > get it to build "out of the box". Perhaps it should first check > for MSVCVER and if not defined fallback on _NMAKE_VER. Thoughts? > This would be fine! Best regards Mathias
Re: VC8 makefile patch
Hi again!
I have realised that on my laptop that I am using at work there is a
nmake version 6.00.9782.0 which isn't in the version list of your
make_mvc.mak patch. I therefore definitively suggest to omit this
version list an relay solely on the MSVCVer environment variable
which should be defined since VC tool chain version 7.0. One can
force the user to define this variable with an !error directive or
one can utilize version 6.0 as standard. This may be a matter of taste.
Therefore, I suggest the patch that is attached to this email.
With kind regards
Mathias
Problem:VC8 no longer supports the /Gn processor code generation
directive, and the makefile now uses link time code
generation when not optimizing for space with an error
message.
Solution: Check version of the visual tool set and, if version is
8.0, use VC8 specific optimization options.
Files: src/Make_mvc.mak
*** ..\vim-7.0.000\src\Make_mvc.mak 2006-04-26 12:30:22.0 +0200
--- src\Make_mvc.mak2007-01-20 20:29:44.430628800 +0100
***
*** 320,326
--- 320,334
INTDIR=$(OBJDIR)
OUTDIR=$(OBJDIR)
+ # We must know the version of the visual C tool chain.
+ !ifndef MSVCVER
+ !message Environment variable MSVCVer not defined. Please set it to the
version of your
+ !message visual C tool chain. Possible values are 4.0, 5.0, 6.0, 7.0, 7.1 and
8.0.
+ !error Environment variable MSVCVer is undefined!
+ !endif
+
# Convert processor ID to MVC-compatible number
+ !if "$(MSVCVER)" != "8.0"
!if "$(CPUNR)" == "i386"
CPUARG = /G3
!elseif "$(CPUNR)" == "i486"
***
*** 334,339
--- 342,353
!else
CPUARG =
!endif
+ !else
+ # VC8 only allows specifying SSE architecture
+ !if "$(CPUNR)" == "pentium4"
+ CPUARG = /arch:SSE2
+ !endif
+ !endif
!ifdef NODEBUG
VIM = vim
***
*** 344,349
--- 358,369
!else # MAXSPEED
OPTFLAG = /Ox
!endif
+ !if "$(MSVCVER)" == "8.0"
+ # Use link time code generation if not worried about size
+ !if "$(OPTIMIZE)" != "SPACE"
+ OPTFLAG = $(OPTFLAG) /GL
+ !endif
+ !endif
CFLAGS = $(CFLAGS) $(OPTFLAG) -DNDEBUG $(CPUARG)
RCFLAGS = $(rcflags) $(rcvars) -DNDEBUG
! ifdef USE_MSVCRT
***
*** 363,369
CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od
RCFLAGS = $(rcflags) $(rcvars) -D_DEBUG -DDEBUG
# The /fixed:no is needed for Quantify. Assume not 4.? as unsupported in
VC4.0.
! ! if "$(_NMAKE_VER)" == ""
LIBC =
! else
LIBC = /fixed:no
--- 383,389
CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od
RCFLAGS = $(rcflags) $(rcvars) -D_DEBUG -DDEBUG
# The /fixed:no is needed for Quantify. Assume not 4.? as unsupported in
VC4.0.
! ! if "$(MSVCVER)" == "4.0"
LIBC =
! else
LIBC = /fixed:no
***
*** 707,712
--- 727,741
$(MZSCHEME_LIB) $(PERL_LIB) $(PYTHON_LIB) $(RUBY_LIB) \
$(TCL_LIB) $(NETBEANS_LIB) $(XPM_LIB) $(LINK_PDB)
+ # Report link time code generation progress if used.
+ !ifdef NODEBUG
+ !if "$(MSVCVER)" == "8.0"
+ !if "$(OPTIMIZE)" != "SPACE"
+ LINKARGS1 = $(LINKARGS1) /LTCG:STATUS
+ !endif
+ !endif
+ !endif
+
all: $(VIM).exe vimrun.exe install.exe uninstal.exe xxd/xxd.exe \
GvimExt/gvimext.dll
***
*** 795,801
# Create a default rule for transforming .c files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF "$(_NMAKE_VER)" == ""
.c{$(OUTDIR)/}.obj:
!ELSE
.c{$(OUTDIR)/}.obj::
--- 824,830
# Create a default rule for transforming .c files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF "$(MSVCVER)" == "4.0"
.c{$(OUTDIR)/}.obj:
!ELSE
.c{$(OUTDIR)/}.obj::
***
*** 804,810
# Create a default rule for transforming .cpp files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF "$(_NMAKE_VER)" == ""
.cpp{$(OUTDIR)/}.obj:
!ELSE
.cpp{$(OUTDIR)/}.obj::
--- 833,839
# Create a default rule for transforming .cpp files to .obj files in $(OUTDIR)
# Batch compilation is supported by nmake 1.62 (part of VS 5.0) and later)
! !IF "$(MSVCVER)" == "4.0"
.cpp{$(OUTDIR)/}.obj:
!ELSE
.cpp{$(OUTDIR)/}.obj::
Re: VC8 makefile patch
Hi Mike Thanks a lot for your patch. If the appropriate compiler options are applied to VC8, the make_mvc.mak script emits much less warning messages, and probably the created binary is better optimised in some manner. Alas, your patch doesn't work on my machine for three reasons: 1) I use VCExpress version to build vim. This is VC8, but there is no SDK. So I also downloaded the Windows Server 2003 R2 Platform SDK. This SDK was the newest when I downloaded it. Alas it comes with nmake version 7.00.xyz. So I have to use nmake 7.00.xyz to control VC8. Solution: make_mvc.mak should not estimate the version of the nmake utility, but of the compiler that is used. This is a little bit difficult, but since version 7.0 of the VC toolset there exists a environment variable MSVCVer which IMHO should be used when it is defined. 2) The nmake utility that comes with the Windows Server 2003 R2 Platform SDK has the version 7.00.8882. This is none of the versions that your patch is made for. Solution: This version should be added to the list of versions as long a s this list is maintained. Another problem: I have heart of a VC 7.1. But I don't know with which exact version number the related nmake tool comes. So it is doubtful if the version list should be maintained at all, or if one should better relay on the environment variable MSVCVer that can in case of need be defined manually by the user. 3) Your patch uses the operators >, <, >= and <= to compare version numbers. With my nmake-7.00.8882 this doesn't work, even if I omit the quotes around the numbers and the macros. Solution: It's a pity, but one has to work with == and !=. I have applied all the solutions mentioned above (by keeping to maintain the list of nmake versions) and can now build vim successfully. (To be honest: I HAVE to apply other patches too that I once have mailed to this list but seemed to have been ignored?). Best regards and thanks again for this patch Mathias Michaelis Patch U010 Written by Mike Williams <[EMAIL PROTECTED]> and Mathias Michaelis <[EMAIL PROTECTED]> Problem:VC8 no longer supports the /Gn processor code generation directive, and the makefile now uses link time code generation when not optimizing for space with an error message. Solution: Check version of the visual tool set and, if version is 8.0, use VC8 specific optimization options. Files: src/Make_mvc.mak *** ..\vim-7.0.000\src\Make_mvc.mak 2006-04-26 12:30:22.0 +0200 --- src\Make_mvc.mak2007-01-20 12:33:37.088265600 +0100 *** *** 320,326 --- 320,354 INTDIR=$(OBJDIR) OUTDIR=$(OBJDIR) + # Derive version of VC being used + !ifndef MSVCVER + !if "$(_NMAKE_VER)" == "" + MSVCVER = 4.0 + !endif + !if "$(_NMAKE_VER)" == "162" + MSVCVER = 5.0 + !endif + !if "$(_NMAKE_VER)" == "6.00.8168.0" + MSVCVER = 6.0 + !endif + !if "$(_NMAKE_VER)" == "7.00.9466" + MSVCVER = 7.0 + !endif + !if "$(_NMAKE_VER)" == "7.00.8882" + MSVCVER = 7.0 + !endif + !if "$(_NMAKE_VER)" == "8.00.50727.42" + MSVCVER = 8.0 + !endif + !endif + + # Default to VC6 (arbitrarily) if unknown + !ifndef MSVCVER + MSVCVER = 6.0 + !endif + # Convert processor ID to MVC-compatible number + !if "$(MSVCVER)" != "8.0" !if "$(CPUNR)" == "i386" CPUARG = /G3 !elseif "$(CPUNR)" == "i486" *** *** 334,339 --- 362,373 !else CPUARG = !endif + !else + # VC8 only allows specifying SSE architecture + !if "$(CPUNR)" == "pentium4" + CPUARG = /arch:SSE2 + !endif + !endif !ifdef NODEBUG VIM = vim *** *** 344,349 --- 378,389 !else # MAXSPEED OPTFLAG = /Ox !endif + !if "$(MSVCVER)" == "8.0" + # Use link time code generation if not worried about size + !if "$(OPTIMIZE)" != "SPACE" + OPTFLAG = $(OPTFLAG) /GL + !endif + !endif CFLAGS = $(CFLAGS) $(OPTFLAG) -DNDEBUG $(CPUARG) RCFLAGS = $(rcflags) $(rcvars) -DNDEBUG ! ifdef USE_MSVCRT *** *** 363,369 CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od RCFLAGS = $(rcflags) $(rcvars) -D_DEBUG -DDEBUG # The /fixed:no is needed for Quantify. Assume not 4.? as unsupported in VC4.0. ! ! if "$(_NMAKE_VER)" == "" LIBC = ! else LIBC = /fixed:no --- 403,409 CFLAGS = $(CFLAGS) -D_DEBUG -DDEBUG /Od RCFLAGS = $(rcflags) $(rcvars) -D_DEBUG -DDEBUG # The /fixed:no is needed for Quantify. Assume not 4.? as unsupported in VC4.0. ! ! if "$(MSVCVER)" == "4.0" LIBC = ! else LIBC = /fixed:no *** *** 707,712 --- 747,761 $(MZSCHEME_LIB) $(PERL_LIB) $(PYTHON_LIB) $(
Re: Paste as HTML
>>> What is the added value of marking >>> it as HTML on the clipboard? >>> >> The added value is that you are able to paste the text into a word >> processing program like AbiWord, MS Word or StarWriter in a way that >> the HTML-Tags are not shown, but are interpreted by the word >> processing program in order to format the text as it would be >> formatted in a HTML browser. >> >> To achieve this know, I only see one way: Convert your text to HTML, >> then save it as HTML, open it with a web browser, copy it from here >> into the clipboard and paste it into a word processing program. > > Why don't these programs offer the option "paste as HTML"? I mean, the > user must have a choice if he wants the HTML as text or the resulting > markup. > The windows clipboard can contain one and the same data item several time, each time in a different format. If I for instance copy from an HTML browser, the data is contained there in HTML as well as in plain text format. I assume word processing programs offer only the format option they can find within the clipboard and they can handle with. When Vim copies text into the clipboard, it declares this text as plain text, never as HTML. This is why word processing programs interpret this text as plain text and don't offer the same options as for HTML -- even if the text _is_ HTML. IMHO this is ok: In order to tell to a target application what it can do with the data contained in the clipboard, declare its format and don't assume that the user can do this. Of course I have no doubt that there are only intelligent Vim users. But the world of word processing program is another one ;-) With best regards Mathias Michaelis
Re: Paste as HTML
Hello Tony >> To achieve this know, I only see one way: Convert your text to HTML, >> then save it as HTML, open it with a web browser, copy it from here >> into the clipboard and paste it into a word processing program. >> > What about opening the HTML file directly as RTF in a word processor? > I guess the original poster wants to insert code snippets into an already existing documentation. Regards Mathias
Re: Paste as HTML
Hello * > What is the added value of marking > it as HTML on the clipboard? > The added value is that you are able to paste the text into a word processing program like AbiWord, MS Word or StarWriter in a way that the HTML-Tags are not shown, but are interpreted by the word processing program in order to format the text as it would be formatted in a HTML browser. To achieve this know, I only see one way: Convert your text to HTML, then save it as HTML, open it with a web browser, copy it from here into the clipboard and paste it into a word processing program. With best regards Mathias
Re: Patch 7.0.051
Hi Bram > Patch 7.0.051 (after 7.0.44) > Thanks! That resolved my problem! Best regards Mathias
Re: Patch 7.0.044
Dear Bram, dear Tony sorry for responding so late -- since I have a job, I run out of time very often. Maybe I am not making enough use of all the possibilities of vim ... >>> I inspected if_perl.xs and if_perl.c and saw that xsubpp simply removed >>> preprocessor directives such as >>> ! #ifdef FEAT_AUTOCMD >>> out of the code without really make a decision between the #if or #else: >>> Both parts were left. >>> >> I missed this, it compiles OK for me even though the code is wrong. >> Note that I put some white space before the # to make it work for me. >> I noted the space: Alas, xsubpp does not :-( >>> I then found >>> >>> http://perldoc.perl.org/perlxs.html#Inserting-POD%2c-Comments-and-C-Preprocessor-Directives >> >> But that mentions that the preprocessor directives are passed on >> unmodified... That isn't so, this documentation is wrong. > Maybe, I misunderstood the documentation and, based on this, did something that worked. But I thought that this statement is valid only before the "MODULE line" -- before the line that much the regular expression ^\s*MODULE\s*=.*\s\s*PACKAGE\s*=.*$ After that line, the text that begins with "If you use preprocessor directives to choose one of two versions of a function [...]" becomes valid. >> Your solution to duplicate the functions is not nice. >> Yes, it's not nice, it's only a work around until a better solution is found. > Compiling on SuSE 9.3 with gcc 3.3.5 20050117 (prerelease), I also get > no messages for if_perl although the # lines are removed and both > branches (before and after #else) passed on. > The code that results if the directives are cancelled is valid C++, but is not valid C. Maybe that this is the crucial point. > I notice that # directives of all kinds are passed on unmodified > elsewhere in the code; but they have the # in column 1 (sometimes with > spaces after the #). There is also one "# string" in a /* comment */ > which is passed on OK. Maybe xsubpp doesn't recognise lines with spaces > before # as 'preprocessor directives' to be passed on? > I think this is not the point. Since I have no time for quickly trying things out, I can only tell about my speculations: Before the "MODULE line" (see above), # directives are passed unmodified, after that "MODULE line" they are interpreted by xsubpp. My suggestion is to pass the if_perl.xs file first though a C preprocessor, and only after that through xsubpp. If the preprocessor disturb the format of if_perl.xs too much so it can't be parsed by xsubpp anymore, I would try something like rename if_perl.xs to if_perl.xs.orig pre-process if_perl.xs.orig to if_perl.xs.pp copy lines before "MODULE line" from f_perl.xs.orig to if_perl.xs add lines after "MODULE line" form if_perl.xs.pp to if_perl.xs xsubpp if_perl.xs But this are only my speculations ... Best regards Mathias
Patch (unofficial): if_perl.xs is converted to an invalid if_perl.c file
Patch (after 7.0.44)
Problem:xsubpp simply removes the newly added directives form
if_perl.xs when converting it into if_perl.c
Solution: See
http://perldoc.perl.org/perlxs.html#Inserting-POD%2c-Comments-and-C-Preprocessor-Directives
*** ..\vim-7.0.044\src\if_perl.xs 2006-08-08 20:02:34.440876800 +0200
--- src\if_perl.xs 2006-08-08 21:07:26.287076800 +0200
***
*** 1048,1053
--- 1048,1054
}
}
+ #ifdef FEAT_AUTOCMD
void
Set(vimbuf, ...)
VIBUF vimbuf;
***
*** 1068,1102
line = SvPV(ST(i),PL_na);
if (lnum > 0 && lnum <= vimbuf->b_ml.ml_line_count && line != NULL)
{
- #ifdef FEAT_AUTOCMD
aco_save_T aco;
/* set curwin/curbuf for "vimbuf" and save some things */
aucmd_prepbuf(&aco, vimbuf);
! #else
buf_T *save_curbuf = curbuf;
curbuf = vimbuf;
curwin->w_buffer = vimbuf;
- #endif
if (u_savesub(lnum) == OK)
{
ml_replace(lnum, (char_u *)line, TRUE);
changed_bytes(lnum, 0);
}
- #ifdef FEAT_AUTOCMD
- /* restore curwin/curbuf and a few other things */
- aucmd_restbuf(&aco);
- /* Careful: autocommands may have made "vimbuf" invalid! */
- #else
curwin->w_buffer = save_curbuf;
curbuf = save_curbuf;
- #endif
}
}
}
void
Delete(vimbuf, ...)
VIBUF vimbuf;
--- 1069,1131
line = SvPV(ST(i),PL_na);
if (lnum > 0 && lnum <= vimbuf->b_ml.ml_line_count && line != NULL)
{
aco_save_T aco;
/* set curwin/curbuf for "vimbuf" and save some things */
aucmd_prepbuf(&aco, vimbuf);
! if (u_savesub(lnum) == OK)
! {
! ml_replace(lnum, (char_u *)line, TRUE);
! changed_bytes(lnum, 0);
! }
!
! /* restore curwin/curbuf and a few other things */
! aucmd_restbuf(&aco);
! /* Careful: autocommands may have made "vimbuf" invalid! */
! }
! }
! }
!
! #else
! void
! Set(vimbuf, ...)
! VIBUF vimbuf;
!
! PREINIT:
! int i;
! long lnum;
! char *line;
! PPCODE:
! if (buf_valid(vimbuf))
! {
! if (items < 3)
! croak("Usage: VIBUF::Set(vimbuf, lnum, @lines)");
!
! lnum = SvIV(ST(1));
! for(i = 2; i < items; i++, lnum++)
! {
! line = SvPV(ST(i),PL_na);
! if (lnum > 0 && lnum <= vimbuf->b_ml.ml_line_count && line != NULL)
! {
buf_T *save_curbuf = curbuf;
curbuf = vimbuf;
curwin->w_buffer = vimbuf;
if (u_savesub(lnum) == OK)
{
ml_replace(lnum, (char_u *)line, TRUE);
changed_bytes(lnum, 0);
}
curwin->w_buffer = save_curbuf;
curbuf = save_curbuf;
}
}
}
+ #endif
+
+ #ifdef FEAT_AUTOCMD
void
Delete(vimbuf, ...)
VIBUF vimbuf;
***
*** 1130,1144
if (lnum > 0 && lnum <= vimbuf->b_ml.ml_line_count)
{
buf_T *save_curbuf = curbuf;
- #ifdef FEAT_AUTOCMD
aco_save_T aco;
/* set curwin/curbuf for "vimbuf" and save some things */
aucmd_prepbuf(&aco, vimbuf);
- #else
- curbuf = vimbuf;
- curwin->w_buffer = vimbuf;
- #endif
if (u_savedel(lnum, 1) == OK)
{
ml_delete(lnum, 0);
--- 1159,1168
***
*** 1146,1165
if (save_curbuf == curbuf)
check_cursor();
}
- #ifdef FEAT_AUTOCMD
/* restore curwin/curbuf and a few other things */
aucmd_restbuf(&aco);
/* Careful: autocommands may have made "vimbuf" invalid! */
! #else
curwin->w_buffer = save_curbuf;
curbuf = save_curbuf;
- #endif
update_curbuf(VALID);
}
}
}
}
void
Append(vimbuf, ...)
VIBUF vimbuf;
--- 1170,1238
if (save_curbuf == curbuf)
check_cursor();
}
/* restore curwin/curbuf and a few other things */
aucmd_restbuf(&aco);
/* Careful: autocommands may have made "vimbuf" invalid! */
! update_curbuf(VALID);
! }
! }
! }
! }
!
! #else
! void
! Delete(vimbu
Re: Patch 7.0.044
Dear Bram > Patch 7.0.044 > Problem: Perl: setting a buffer line in another buffer may result in > changing the current buffer. > Solution: Properly change to the buffer to be changed. > Files:src/if_perl.xs > > [...] > Alas, if I want to compile this, I get the following output ---%<--- "C:\Program Files\ActivePerl\Bin\perl" "C:\Program Files\ActivePerl\lib\ExtUtils\xsubpp" -prototypes -typemap "C:\Program Files\ActivePerl\lib\ExtUtils\typemap" -typemap typemap if_perl.xs > if_perl.c cl -c /W3 /nologo -D_MT -MT -I. -Iproto -DHAVE_PATHDEF -DWIN32 -DFEAT_SNIFF -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_XPM_W32 -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 /Fo.\ObjGOL/ /Ox -DNDEBUG /G6 -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DGLOBAL_IME -DFEAT_MBYTE -DFEAT_GUI_W32 -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl58.dll\" -DFEAT_HUGE /Zi /Fd.\ObjGOL/ /I "C:\Program Files\ActivePerl\Lib\Core" if_perl.c cl : Command line warning D9002 : ignoring unknown option '/G6' if_perl.c if_perl.xs(1075) : error C2275: 'buf_T' : illegal use of this type as an expression c:\software\vim\vim70\src\structs.h(1133) : see declaration of 'buf_T' if_perl.xs(1075) : error C2065: 'save_curbuf' : undeclared identifier if_perl.xs(1088) : warning C4047: '=' : 'buf_T *' differs in levels of indirection from 'int' if_perl.xs(1089) : warning C4047: '=' : 'buf_T *' differs in levels of indirection from 'int' if_perl.xs(1187) : error C2275: 'buf_T' : illegal use of this type as an expression c:\software\vim\vim70\src\structs.h(1133) : see declaration of 'buf_T' if_perl.xs(1200) : warning C4047: '=' : 'buf_T *' differs in levels of indirection from 'int' if_perl.xs(1201) : warning C4047: '=' : 'buf_T *' differs in levels of indirection from 'int' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. --->%--- I inspected if_perl.xs and if_perl.c and saw that xsubpp simply removed preprocessor directives such as > ! #ifdef FEAT_AUTOCMD > out of the code without really make a decision between the #if or #else: Both parts were left. I then found http://perldoc.perl.org/perlxs.html#Inserting-POD%2c-Comments-and-C-Preprocessor-Directives I will make my patch to get this working With kind regards Mathias
Re: if_ole.cpp triggers warnings on VC++ 2005
>> As it was discussed earlier, on MS VC++ 2005 additional defines is >> required in order to use some of the standard C library functions >> without warnings. This defines should be done before inclusion of a >> windows.h header. This defines was added into vim.h. In if_ole.cpp >> vim.h is included after windows.h. > > Thanks for fixing this. > > The side effects are unpredictable. I'll await comments for a while > before making an official patch for this. > I have applied this patch and compiled (g)vim(d) successfully. Now I am working with this version of vim. If I encounter some problems, I will report them. Are there some special things I have to care about? Or some standardized tests I have to carry out? Best regards Mathias
Re: src/po/README_mvc.txt: Documentation Update
Bram > Thanks for the correction of the typos. > It's a pleasure! >> + Another possibility is to use the gnuwin32 port of gettext. This is >> + recommended especially if you use already gnuwin32 tools to gunzip, bunzip, >> + patch etc. these files. You find the gnuwin32 version of gettext here: >> + >> + http://gnuwin32.sourceforge.net/packages/gettext.htm >> + >> + Yet another very strait forward way is to get the sources of gettext from >> + >> + http://www.gnu.org/software/gettext/gettext.html >> + >> + and build your own version of these tools. The documentation states that >> this >> + should be possible with MSVC4.0, MSVC5.0, MSVC6.0 or MSVC7.0, but you can >> + build it even successfully with MSVC8.0. >> > Did you try these versions? I recall there were problems with some > ported versions of gettext and tools, but perhaps these are fixed by > now. > Yes. I do all my work with gnuwin32. I once compiled gettext with the Visual C++ Toolkit, and yet it works well. With the new Visual 2005 Express Edition (VCEE) you must handle the .manifest files in a similar way as in one of my patches of gvimext.dll. But I didn't make expensive tests with the gettext package compiled by VCEE. The gnuwin32 version as well as the version I once compiled with VC Toolkit of the msgfmt tool has one little problem: I can successfully compile all po files of Vim to mo files -- with one exception: msgfmt -o "vim\vim70\src\po\ja.sjis\LC_MESSAGES\vim.mo" \ "vim\vim70\src\po\ja.sjis.po" says: vim\vim70\src\po\ja.sjis.po:61:23: invalid control sequence vim\vim70\src\po\ja.sjis.po:208:18: invalid control sequence [...] vim\vim70\src\po\ja.sjis.po:1544:34: invalid control sequence vim\vim70\src\po\ja.sjis.po:1566:20: invalid control sequence msgfmt: too many errors, aborting But since the official vim70lang.zip file also doesn't contain a ja.sjis language I thought this behaviour of msgfmt is normal. When I run the Vim version compiled myself on a German computer, all menus and messages are German. With best regards Mathias
Re: Patch 7.0.027 (extra)
Bram
> Patch 7.0.027 (extra)
> [...]
> }
> if (msg.message == WM_USER)
> + {
> + MyTranslateMessage(&msg)
^
c:\devel\vim\vim70\src\gui_w48.c(1669) : error C2146:
syntax error : missing ';' before identifier 'DispatchMessageA'
I know these little nasty things too good myself %-]
Thanks and best regards
Mathias
src/po/README_mvc.txt: Documentation Update
Problem:No Problem! Only some documentation is out dated. I hope this is the correct way how I communicate changes from which I think they could be helpful not only to me. If not, please show me the correct way. Thanks! Solution: This unofficial context patch. Files: src/po/README_mvc.txt *** ..\vim-7.0.000\src\po\README_mvc.txt2004-06-07 16:32:21.0 +0200 --- src\po\README_mvc.txt 2006-06-20 12:05:49.898793600 +0200 *** *** 4,19 gnu-gettext.win32, a Windows port of gettext by Franco Bez <[EMAIL PROTECTED]>. You can find it at: ! http://home.a-city.de/franco.bez/gettext/gettext_win32_en.html First read the README.txt file in this directory for general remarks on translating Vim messages. SETUP ! Set the enviroment variable LANGUAGE to the language code for the language you ! are translating Vim messages to. Languagde codes are typically two characters and you can find a list of them at: http://www.geocities.com/click2speak/languages.html --- 4,33 gnu-gettext.win32, a Windows port of gettext by Franco Bez <[EMAIL PROTECTED]>. You can find it at: ! http://people.freenet.de/franco.bez/gettext/gettext_win32_en.html First read the README.txt file in this directory for general remarks on translating Vim messages. + Another possibility is to use the gnuwin32 port of gettext. This is + recommended especially if you use already gnuwin32 tools to gunzip, bunzip, + patch etc. these files. You find the gnuwin32 version of gettext here: + + http://gnuwin32.sourceforge.net/packages/gettext.htm + + Yet another very strait forward way is to get the sources of gettext from + + http://www.gnu.org/software/gettext/gettext.html + + and build your own version of these tools. The documentation states that this + should be possible with MSVC4.0, MSVC5.0, MSVC6.0 or MSVC7.0, but you can + build it even successfully with MSVC8.0. + SETUP ! Set the environment variable LANGUAGE to the language code for the language you ! are translating Vim messages to. Language codes are typically two characters and you can find a list of them at: http://www.geocities.com/click2speak/languages.html *** *** 23,29 Advanced tab in the System control panel. Next, edit Make_mvc.mak so that GETTEXT_PATH points the binary directory of ! the intallation. CREATING A NEW TRANSLATION --- 37,43 Advanced tab in the System control panel. Next, edit Make_mvc.mak so that GETTEXT_PATH points the binary directory of ! the installation. CREATING A NEW TRANSLATION *** *** 43,49 You will also need to edit the file names in the comments in the .po file. You need to remove the absolute directory specification (which has the form c:\vim61\src\). You can do this in Vim with the following command with the ! appropriate directory specfication for where you have installed the Vim source: %s/c:\\vim61\\src\\//g --- 57,63 You will also need to edit the file names in the comments in the .po file. You need to remove the absolute directory specification (which has the form c:\vim61\src\). You can do this in Vim with the following command with the ! appropriate directory specification for where you have installed the Vim source: %s/c:\\vim61\\src\\//g *** *** 57,63 nmake -f Make_mvc.mak xx.po ! where xx is the langauge code for the language needing translations. The original .po file is copied to xx.po.orig. --- 71,77 nmake -f Make_mvc.mak xx.po ! where xx is the language code for the language needing translations. The original .po file is copied to xx.po.orig. -- Thanks a lot for the VIM Editor! Greetings Mathias
Re: Patch: gvimext.dll don't find MSVCR80.dll when built with VC8. No context menu entries.
Hi * > Please retrieve _all_ my patches from the archive > > http://members.tcnet.ch/michaelis/vim/patches_vim_1.zip > > and pick out the ones that concern the mvc makefiles. > > Since only a view of my patches I published here have been discussed > until now, I am afraid that the other ones could gone lost in the > traffic of this list. Here is a list of all my patches so far: > > http://groups.yahoo.com/group/vimdev/message/43821 > http://groups.yahoo.com/group/vimdev/message/43825 > http://groups.yahoo.com/group/vimdev/message/43850 > http://groups.yahoo.com/group/vimdev/message/43920 > http://groups.yahoo.com/group/vimdev/message/43921 > http://groups.yahoo.com/group/vimdev/message/43924 > http://groups.yahoo.com/group/vimdev/message/43934 > Uups -- my fears have become true: I've forgot one: http://groups.yahoo.com/group/vimdev/message/43765 I have recreated patches_vim_1.zip (above), it should now be up to date. I'm sorry! Best regards Mathias
Re: Patch (unofficial): Create PDBs and EXEs within same directory
Bram Patch Problem: IMHO .pdb files should reside in the same directory as the corresponding .exe files so they can be distributet along with them. >>> This doesn't matter for the distribution, the .pdb file can be moved >>> around after generating it. It might matter for when you want to run >>> Vim right after compiling it. I haven't tried it. >>> >> [...] >> Thus, if you have gvim, gvimd, vim and vimd in your >> $VIMRUNTIME directory, you need four(!) subdirectories named >> "OBJ..." there, each of them containing only one file: the >> corresponding .PDB file. >> >> Otherwise, you can't debug the executables without first guide your >> debugger to the location where the corresponding .pdb file is stored. > > Do you mean that the subdirectory is stored in the executable? > Yes. Now I did some tests, but the results are not the same as I mean to have experienced the first times when I started compiling vim. Anyway: The full (alas not relative) path to the .pdb file is stored in the .exe file. Some information on this can be found here: http://msdn2.microsoft.com/en-us/library/yd4f8bd1.aspx Although stated otherwise in this link, I experienced that if the .pdb can't be found at the location stored in the .exe file, it is searched in the directory where the .exe file resides (and maybe even in all directories listed in the PATH environment variable). So that would invalidate my arguments above, but I have more arguments: >> This is why I plead to make this patch an official one :-) >> > The reason to put the .pdb file, and any other generated files, > in a subdirectory is to keep the source directory clean. And to > have a different subdirectory for the various versions. > 1. The .pdb files are named like their corresponding .exe files (vim.pdb, vimd.pdb, gvim.pdb, gvimd.pdb), while the .obj files (and pathdef.c) have always the same name. So for the latter it makes sense to store them into specially named directories in order to be able to distinguish them, while the former ones can be distinguished already by their file names. 2. If you change the configuration of, say, gvimd (e.g. add an additional feature), the argument 1. above in not valid any more. But in this case you anyway must delete (or move into the right Obj... directory) the .exe file first, and the same is just true for the .pdb file: .pdb files can be treated as a part of an .exe file that is swapped out into a special file. 3. If you want to automate the process of building vim and move the .exe and .pdb files together into an appropriate $VIMRUNTIME directory by means of a BATCH or BASH script, then it is a nasty task to code the cryptical name of the Obj... directory into that script and change it whenever you change the list of features you want to have compiled into your Vim. Not only isn't it easy to find out the name of the Obj... directory that will be created by a certain feature list, but you also must ensure that none of the patches you may apply to the Vim sources changes that connection of the feature list on the one hand and the name of the Obj... directory on the other hand. For all this reasons, I yet plead to put the .pdb file into the same directory as the .exe files. But as I mentioned, it's only IMHO :-) Best regards Mathias
Re: PC sources lacks if_sniff.c
Bram >>> The source archive >>> >>> ftp://ftp.vim.org/pub/vim/pc/vim70src.zip >>> >>> contains the file if_sniff.h but not the corresponding source file >>> if_sniff.c. Has this a specific reason or has if_sniff.c simply been >>> forgotten? >>> > The Sniff interface is something extra, you need to get it from the > extra archive. That's how it is. > Hmmm ... 1. The extra archive mainly consists on platform specific files and on sub projects like tee, xxd or testdir. Some of the sub projects are included in the pc archive (xxd, testdir), others are not (tee). Well, for my compilations, I use tee too, but get it from the gnuwin32 project. Now, sniff.c is whether platform specific nor a sub project, but is an optional component of Vim, probably similar to fold.c. I have no big knowledge about Vim and its source, but it's not easy to me to see why sniff.c logically belongs into the extra archive, while sniff.h is in the source archive. 2. But there is a practical reason too why this item keeps me busy: If I set SNIFF=yes within Make_mvc.mak, I get an error message from the linker that a certain module could not be found. For me as a silly Windows user it needs some time to find out - that this is due to a missing file - that this file can be found in the extra archive for unix - that this is a feature and not a bug, so I must not give up Besides of this, I can't refrain to summarise my experiences like that: With the unique exception of patch.exe from gnuwin32 where I needed to apply the switch --binary, all other build tools (e.g. from Microsoft VS2005) didn't have any problems with unix style line ends (LF) instead of dos style line ends (CRLF). So it is almost easier to work with the unix .tar.gz archives than with the .zip archives that are kindly supplied for Windows and Dos users. Best regards Mathias
Re: Patch: gvimext.dll don't find MSVCR80.dll when built with VC8. No context menu entries.
Bram, George >>> Patch 7.0.Make_GvimExt >>> >> I don't have this compiler. Can someone with MSVC 2005 verify this >> works properly? >> > Send me the patch and I'll try it out. > Please retrieve _all_ my patches from the archive http://members.tcnet.ch/michaelis/vim/patches_vim_1.zip and pick out the ones that concern the mvc makefiles. Since only a view of my patches I published here have been discussed until now, I am afraid that the other ones could gone lost in the traffic of this list. Here is a list of all my patches so far: http://groups.yahoo.com/group/vimdev/message/43821 http://groups.yahoo.com/group/vimdev/message/43825 http://groups.yahoo.com/group/vimdev/message/43850 http://groups.yahoo.com/group/vimdev/message/43920 http://groups.yahoo.com/group/vimdev/message/43921 http://groups.yahoo.com/group/vimdev/message/43924 http://groups.yahoo.com/group/vimdev/message/43934 With best regards Mathias
Re: Patch: Make_mvc.mak creates an empty gvim.exe.mnf file
Bram Patch Problem:Make_mvc.mak creates an empty gvim.exe.mnf file (or stops with an error message). Solution: Don't use 'echo' to create files. Use inline files instead. Files: src/Make_mvc.mak > Before including this change I would have to check the file still works > with old versions of MSVC. I still need to use 4.1 to be able to > generate a win32s version. > I have downloaded NMAKE 1.5 from http://support.microsoft.com/default.aspx?scid=kb;en-us;Q132084#appliesto and saw, that it can handle inline files too. I think NMAKE 1.5 is only a bug fix release with no additional features so NMAKE 1.4 should also handle inline files. The actual version on NMAKE is about 8.00.xxx. The method of using inline files is much more reliable than using "echo", by reasons mentioned already at other places of that thread. With best regards Mathias
Re: Patch (unofficial): Create PDBs and EXEs within same directory
Bram >> Patch >> Problem:IMHO .pdb files should reside in the same directory as the >> corresponding .exe files so they can be distributet along >> with them. >> Solution: Change one line within src/Make_mvc.mak >> Files: src/Make_mvc.mak >> > This doesn't matter for the distribution, the .pdb file can be moved > around after generating it. It might matter for when you want to run > Vim right after compiling it. I haven't tried it. > Of course: If the pdb file is created in a subdirectory OBJGO, then you must move this directory when ever you move the corresponding Vim .EXE file. Thus, if you have gvim, gvimd, vim and vimd in your $VIMRUNTIME directory, you need four(!) subdirectories named "OBJ..." there, each of them containing only one file: the corresponding .PDB file. Otherwise, you can't debug the executables without first guide your debugger to the location where the corresponding .pdb file is stored. And yes: the .PDB are not needed for a distribution. But this is no reason to hide these files in some subdirectories. Maybe, someone wants to copy these files in the same $VIMRUNTIME directory as the executable files. Or even wants to create his own distribution that contains these files -- as Antoine Mechelynck contributed the debugging executables vimd.exe and gvimd.exe at the times when he compiled Vim. This is why I plead to make this patch an official one :-) Best regards Mathias
Re: Patch: Make_mvc.mak creates an empty gvim.exe.mnf file
Bram
>> Patch
>> Problem:Make_mvc.mak creates an empty gvim.exe.mnf file
>> (or stops with an error message).
>> Solution: Don't use 'echo' to create files. Use inline files
>> instead.
>> Files: src/Make_mvc.mak
>
> This has always worked just fine. When does it fail?
>
The gvim.exe.mnf always was empty -- but as George Reilly (who made
the skipt) told me, it is only used for 64-Bit Windows.
On the other hand, the error message ("FATAL error: echo returned
'1'") was only issued from time to time, depending on the commands I
typed in before. However, the message appeared in a reproducible
manner if I issued the nmake command from within a BATCH file.
I checked the documentation of nmake from VC 8.0 (VS 2005) and from
VC 6.0 to see if inline files can be handled. Since it is possible
and since I can compile Vim _only_ like that, I'm pretty sure this
patch facilitate the life of many users.
My environment: Visual Studio 2005 Express Edition.
C:>cmd -version
Microsoft Windows XP [Version 5.1.2600]
C:>nmake /?
Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
With best regards
Mathias
Re: gvim crash after closing: gvim hanging in Windows XP Taskmanager
Hi vimmers I have some news about the crash -- finally I found the cause. > I don't know how to find out where the problem is. Perhaps, there > are some resources yet occupied, or some messages in a message > queue of some hidden windows, that leads OleUninitialize() to stop > the whole program at the end of a vim session -- I'm not a > specialist for such things. > I think the last thought was actually the reason of the crash. See: http://groups.yahoo.com/group/vimdev/message/43934 Best regards Mathias
Patch (unofficial): OLE & SNIFF enabled gvim crashes on Windows by closing
Patch (unofficial)
Problem:OLE & SNIFF enabled gvim crashes on Windows by issuing the
command :q after 10 minutes
Solution: Do translate and dispatch all messages. They may be addressed
to some thread of hidden window created by the os.
Files: src/gui_w48.c
*** ..\vim-7.0.000\src\gui_w48.c2006-05-07 16:13:02.0 +0200
--- src\gui_w48.c 2006-06-12 12:17:56.160569600 +0200
***
*** 1664,1670
--- 1664,1674
/* request is handled in normal.c */
}
if (msg.message == WM_USER)
+ {
+ MyTranslateMessage(&msg);
+ DispatchMessage(&msg);
return;
+ }
#endif
#ifdef MSWIN_FIND_REPLACE
Patch (unofficial): Synchronize documetation of Makefile with my patched src/Make_mvc.mak (Thanks to Ylia)
Patch 7.0.Makefile
Problem:IMHO .pdb files should reside in the same directory as the
corresponding .exe files so they can be distributet along
with them. Therefore, one of my recent patches adopted
src/Make_mvc.mak to that opinion. Alas, now the top level
Makefile is out of sync.
Solution: Change documentation within ./Makefile (thanks to Ilya
)
Files: ./Makefile
*** ..\vim-7.0.000\Makefile 2006-05-07 14:16:24.0 +0200
--- .\Makefile 2006-06-09 17:34:43.712491200 +0200
***
*** 132,151
# - "nmake -f Make_mvc.mak"
# - "rm testdir/*.out", "nmake -f Make_mvc.mak test" and check the output.
# - Rename the executables to "vimw32.exe", "xxdw32.exe".
! # - Rename ObjC/vim.pdb to vimw32.pdb.
# - When building the Win32s version later, delete vimrun.exe, install.exe and
# uninstal.exe. Otherwise rename executables to installw32.exe and
# uninstalw32.exe.
# Win32 GUI version:
# - "nmake -f Make_mvc.mak GUI=yes.
# - move "gvim.exe" to here (otherwise the OLE version will overwrite it).
! # - Move ObjG/gvim.pdb to here.
# - Delete vimrun.exe, install.exe and uninstall.exe.
# - Copy "GvimExt/gvimext.dll" to here.
# Win32 GUI version with OLE, PERL, TCL, PYTHON and dynamic IME:
# - Run src/bigvim.bat ("nmake -f Make_mvc.mak GUI=yes OLE=yes IME=yes ...)
# - Rename "gvim.exe" to "gvim_ole.exe".
! # - Rename ObjGOLYTR/gvim.pdb to "gvim_ole.pdb".
# - Delete install.exe and uninstall.exe.
# - If building the Win32s version delete vimrun.exe.
# Win32s GUI version:
--- 132,151
# - "nmake -f Make_mvc.mak"
# - "rm testdir/*.out", "nmake -f Make_mvc.mak test" and check the output.
# - Rename the executables to "vimw32.exe", "xxdw32.exe".
! # - Rename vim.pdb to vimw32.pdb.
# - When building the Win32s version later, delete vimrun.exe, install.exe and
# uninstal.exe. Otherwise rename executables to installw32.exe and
# uninstalw32.exe.
# Win32 GUI version:
# - "nmake -f Make_mvc.mak GUI=yes.
# - move "gvim.exe" to here (otherwise the OLE version will overwrite it).
! # - Move gvim.pdb to here.
# - Delete vimrun.exe, install.exe and uninstall.exe.
# - Copy "GvimExt/gvimext.dll" to here.
# Win32 GUI version with OLE, PERL, TCL, PYTHON and dynamic IME:
# - Run src/bigvim.bat ("nmake -f Make_mvc.mak GUI=yes OLE=yes IME=yes ...)
# - Rename "gvim.exe" to "gvim_ole.exe".
! # - Rename gvim.pdb to "gvim_ole.pdb".
# - Delete install.exe and uninstall.exe.
# - If building the Win32s version delete vimrun.exe.
# Win32s GUI version:
--
Thanks a lot for the VIM Editor!
Greetings
Mathias
Patch (unofficial): xpm_w32 support now possible with spaces in path names
Patch Problem:When trying to buid vim with xpm_w32 support, the Make_mvc runs into troubles as soon as the path names of required libraries and include files contain spaces. Solution: Quote such path names. Files: src/Make_mvc.mak *** ..\vim-7.0.000\src\Make_mvc.mak 2006-06-09 09:55:53.956646400 +0200 --- src\Make_mvc.mak2006-06-09 10:40:59.957684800 +0200 *** *** 262,272 !ifdef XPM # XPM - Include support for XPM signs ! # you can get xpm.lib from http://iamphet.nm.ru/xpm or create it yourself XPM_OBJ = $(OBJDIR)/xpm_w32.obj XPM_DEFS = -DFEAT_XPM_W32 XPM_LIB = "$(XPM)\lib\libXpm.lib" ! XPM_INC = -I $(XPM)\include !endif !endif --- 262,272 !ifdef XPM # XPM - Include support for XPM signs ! # you can get xpm.lib from http://gnuwin32.sourceforge.net/packages/xpm.htm XPM_OBJ = $(OBJDIR)/xpm_w32.obj XPM_DEFS = -DFEAT_XPM_W32 XPM_LIB = "$(XPM)\lib\libXpm.lib" ! XPM_INC = -I "$(XPM)\include" -I "$(XPM)\include\x11" !endif !endif *** *** 962,967 --- 962,974 E0_CFLAGS = $(CFLAGS:\=\\) E_CFLAGS = $(E0_CFLAGS:"=\") + # $LINKARGS1 and $LINKARGS2 may contain backslashes and double quotes. + # Excape them both. + E0_LINKARGS1 = $(LINKARGS1:\=\\) + E_LINKARGS1 = $(E0_LINKARGS1:"=\") + E0_LINKARGS2 = $(LINKARGS2:\=\\) + E_LINKARGS2 = $(E0_LINKARGS2:"=\") + $(PATHDEF_SRC): auto @echo creating $@ @copy << $@ *** *** 970,976 char_u *default_vim_dir = (char_u *)"$(VIMRCLOC:\=\\)"; char_u *default_vimruntime_dir = (char_u *)"$(VIMRUNTIMEDIR:\=\\)"; char_u *all_cflags = (char_u *)"$(CC:\=\\) $(E_CFLAGS)"; ! char_u *all_lflags = (char_u *)"$(link:\=\\) $(LINKARGS1:\=\\) $(LINKARGS2:\=\\)"; char_u *compiled_user = (char_u *)"$(USERNAME)"; char_u *compiled_sys = (char_u *)"$(USERDOMAIN)"; << --- 977,983 char_u *default_vim_dir = (char_u *)"$(VIMRCLOC:\=\\)"; char_u *default_vimruntime_dir = (char_u *)"$(VIMRUNTIMEDIR:\=\\)"; char_u *all_cflags = (char_u *)"$(CC:\=\\) $(E_CFLAGS)"; ! char_u *all_lflags = (char_u *)"$(link:\=\\) $(E_LINKARGS1) $(E_LINKARGS2)"; char_u *compiled_user = (char_u *)"$(USERNAME)"; char_u *compiled_sys = (char_u *)"$(USERDOMAIN)"; << -- Thanks a lot for the VIM Editor! Greetings Mathias
Patch (unofficial): Create PDBs and EXEs within same directory
Patch Problem:IMHO .pdb files should reside in the same directory as the corresponding .exe files so they can be distributet along with them. Solution: Change one line within src/Make_mvc.mak Files: src/Make_mvc.mak *** ..\vim-7.0.000\src\Make_mvc.mak 2006-06-04 18:09:36.210426300 +0200 --- src\Make_mvc.mak2006-06-05 19:02:19.844152000 +0200 *** *** 683,689 # on a crash (doesn't add overhead to the executable). # CFLAGS = $(CFLAGS) /Zi /Fd$(OUTDIR)/ ! LINK_PDB = /PDB:$(OUTDIR)/$(VIM).pdb -debug # -debug:full -debugtype:cv,fixup # # End extra feature include --- 683,689 # on a crash (doesn't add overhead to the executable). # CFLAGS = $(CFLAGS) /Zi /Fd$(OUTDIR)/ ! LINK_PDB = /PDB:$(VIM).pdb -debug # -debug:full -debugtype:cv,fixup # # End extra feature include -- Thanks a lot for the VIM Editor! Greetings Mathias
Re: gvim crash after closing: gvim hanging in Windows XP Taskmanager
Hi vimmers I have some news about the crash. 1) Minimal requirement to build a gvim.exe that crashes with Microsoft Visual Studio 2005 Express Edition (VSEE): nmake -f Make_mvc.mak FEATURES=NORMAL GUI=yes OLE=yes \ MBYTE=no IME=no GIME=no SNIFF=yes CSCOPE=no \ ICONV=no GETTEXT=no POSTSCRIPT=no That means: gvim.exe has the problem only if all three following conditions are met: a) OLE=yes b) SNIFF=yes c) Close gvim.exe only after 15 minutes Sometimes, gvim seems to close properly, but in the Taskmanager one can see that gvim is yet there. 2) One can also build a huge debug version of vim and enable much more feature to let gvim show this behaviour. 3) The crash happens as follows: Within the source file src/os_mswin.c the function mch_exit() is called as soon as you press :q within gvim.exe. Now, the function UninitOLE(), defined in src/if_ole.c, called. This function calls the Windows API function OleUninitialize(), which alas never returns. I don't know how to find out where the problem is. Perhaps, there are some resources yet occupied, or some messages in a message queue of some hidden window, that leads OleUninitialize() to stop the whole program -- I'm not a specialist for such things. 4) Why does this happen only after gvim was running for 10 minutes or more? Perhaps this also depends on a time constant of the operating system: I had read somewhere that Windows unloads all 10 minutes some dlls that seam to not be in use any more. My work around: Don't use the SNIFF feature on Windows. Apropos SNIFF: The source file if_sniff.c is missing in the pc source package ftp://ftp.vim.org/pub/vim/pc/vim70src.zip. I got it from ftp://ftp.vim.org/pub/vim/extra/vim-7.0-extra.tar.gz. As mentioned in http://groups.yahoo.com/group/vimdev/message/43780, I'm not sure if that has a reason or not. Strange coincidence! With best regards Mathias
Re: matchparen bug?
Hi * > I call that reproducing the bug. That makes three of us who see > the bug, one who does not. Looking at the plugin, I think I > understand what causes it. I explained that a few posts back, > didn't I? > Bram has fixed this bug already a month ago ;-) See: http://groups.yahoo.com/group/vimdev/message/43639 Best regards Mathias
Re: gvim crash after closing: gvim hanging in Windows XP Taskmanager
Tony >> But if I invoke the Taskmanager by pressing Ctrl-Alt_Delete, >> then I observe a gvim zombie hanging around within the task >> list. >> > If it doesn't happen when you build with Big features (and an > otherwise identical configuration), then the only difference > between Big and Hige is that the latter has +profile > Thanks for that hint! I am doing some researches about this issue and am glad about such tips. Sincerely Mathias
Re: All mails lost
Yakov > ... That's why re-sending helps. > Thanks again! Yes, I experienced that once or twice too. But this time, waiting one night didn't help, so I thought it stays like that for ever: I am receiving mails, can't reply nor unsubscribe nor influence in any way what's going on. This is why I was a little bit in panic. Excuse me! Sincerely Mathias
Re: All mails lost
Tony > > I found that emails that are written on my Thunderbird Email > > Client AND where addressed to vim-dev@vim.org ... were filtered > > away, ... > > > There may be an explanation to that: Thunderbird writes its mail in HTML > by default, ... > Thanks for reply -- I appreciate that also those nasty problems are discussed seriously. But anyway: I don't write HTML emails, I turn this (un-)feature off where ever it is possible. So this explanation can be excluded. Sincerely Mathias Webmail TcNet GmbH http://www.tcnet.ch
Re: All mails lost
Hello Matthew, dear developers >> My emails are systematically filtered out. >> > I'm seeing your messages on the list. > First: Thanks for replying so fast! But: You don't see no of my mails written yesterday, and also not all from this morning. The testmail written at 09:03:28 +0200 is not from me, but from my Email-Provider. I found that emails that are written on my Thunderbird Email Client AND where addressed to vim-dev@vim.org or an address to unsubscribe from the list where filtered away, BUT emails written on the web interface of my ISP reached the list. I can verify that on the mail archive http://groups.yahoo.com/group/vimdev Although I have unsubscribed my self, I yet receive emails from the list and - suddenly - I can send emails again to the list. Very curious! > There have been situations in the past where the list has > silently discarded messages because they don't match some > arbitrary unpublished criterion, but that doesn't appear to be > the case here. > First I thought emails must not be written on Thunderbird, but that apparently isn't true any more. > [cc'd to poster to be certain the message gets through] > Thanks again for your reply! Best regards Mathias
gvim crash after closing: gvim hanging in Windows XP Taskmanager
Dear developers I observe the following strange behaviour of gvim 7.0 on Windows XP built with HUGE features by my own: I open gvim.exe, work with it or leave it without touching it for half an hour. Then, within gvim.exe, I type ":q" or ":wq". gvim saves the text, remove the .swp file and closes its window -- all as expected. But if I invoke the Taskmanager by pressing Ctrl-Alt_Delete, then I observe a gvim zombie hanging around within the task list. I have tried all to make this phenomena more reproducible, but nothing helps: You may open and close gvim hundred times, or may open and close with gvim a hundred files, you may do heavy work with it or can leave it alone, all that does not matter. The only thing that matters is the time you keep gvim open: On my (old) machine, gvim closes properly if I quit it after five minutes, but if I quit it only after 30 minutes, it keeps hanging around in the task list. There is a second parameter that matters: The features you include into your built of gvim. Alas, I could not yet found clearly, which features this strange behaviour depends on. Has anybody similar effects? Or do I do something wrong? See below how I built my version of gvim. Thanks very much for any help, hints, proposals or anything that could help to trace down this effect. With kind regards Mathias -- How I built my version of gvim: I used the sources I found under ftp://ftp.vim.org/pub/vim/pc/vim70src.zip ftp://ftp.vim.org/pub/vim/pc/vim70rt.zip ftp://ftp.vim.org/pub/vim/pc/vim70lang.zip and used also if_sniff.c from ftp://ftp.vim.org/pub/vim/extra/vim-7.0-extra.tar.gz I applied all 17 patches I've grabbed from ftp://ftp.vim.org/pub/vim/patches/7.0 and also applied my own patches I sent to this list: http://groups.yahoo.com/group/vimdev/message/43765 http://groups.yahoo.com/group/vimdev/message/43821 http://groups.yahoo.com/group/vimdev/message/43825 http://groups.yahoo.com/group/vimdev/message/43850 To build gvim.exe, I used Microsoft Visual Studio 2005 Express Edition (VSEE) and issued the commands call "%VC8_DIR%\bin\vcvars32.bat" call "%SDK_DIR%\setenv" /XP32 /RETAIL nmake -f Make_mvc.mak FEATURES=HUGE GUI=yes OLE=yes \ MBYTE=yes IME=yes GIME=yes SNIFF=yes CSCOPE=yes \ ICONV=yes GETTEXT=yes POSTSCRIPT=no CPUNR=i686 \ WINVER=0x0500 PERL="%ProgramFiles%\ActivePerl" \ DYNAMIC_PERL=yes PERL_VER=58 Then I installed gvim by copying the .exe and .dlls as well as the runtime files to %ProgramFiles%\Vim\vim70 and by running install.exe. All worked great!
testmail
testmail
All mails lost
Dear developers My emails are systematically filtered out. I can't even unsubscribe (why be on a list where own, very carefully composed contributions aren't desired?). I already have phoned to my ISP, and he's innocent. Now I am really helpless. If this email reaches the list, I will once more try to logout myself. Best regards Mathias Webmail TcNet GmbH http://www.tcnet.ch
testmail
testmail Webmail TcNet GmbH http://www.tcnet.ch
Re: VS2005 linking errors with FEATURES=TINY GUI=yes OLE=yes
Hi Tony Thanks for your reply! >> If I compile vim on Windows XP with Microsoft Visual Studio >> 2005 Express Edition on the command line with >> >> nmake -f Make_mvc.mak DEBUG=yes FEATURES=TINY GUI=yes OLE=yes >> >> I get the [some] errors: >> > I guess it's a bug; but "Tiny" features means barest bones, > without arithmetic evaluation and without syntax highlighting. I > don't recommend it. > There is another bug that leads vim to crash sometimes. I will report it here as soon I can describe it in a reproducible manner. Anyway, I am trying to create a vim that is as small as possible but in spite of that has the property to crash. I hope it is easier to trace down the cause of the crash in a tiny vim than in a huge one. With best regards Mathias
Patch: nmake DEBUG=yes FEATURES=NORMAL GUI=yes OLE=yes fails
Patch 7.0.mswin Problem:On Windows, when gvim is built by the command nmake -f Make_mvc.mak DEBUG=yes FEATURES=NORMAL GUI=yes OLE=yes then the linker will issue the error message if_ole.obj : error LNK2019:i unresolved external symbol _MultiByteToWideChar_alloc referenced in function "public: virtual long __stdcall CVim::Eval(wchar_t *,wchar_t * *)" Solution: Include this function into the built also when OLE is enabled. Files: src/mswin.c *** ..\vim-7.0.000\src\os_mswin.c 2006-05-07 16:13:03.0 +0200 --- src\os_mswin.c 2006-06-04 17:38:32.981234300 +0200 *** *** 957,962 --- 957,966 return outlen; } + #endif /* FEAT_MBYTE */ + + #if defined(FEAT_MBYTE) || defined(FEAT_OLE) || defined(PROTO) + /* * Call MultiByteToWideChar() and allocate memory for the result. * Returns the result in "*out[*outlen]" with an extra zero appended. *** *** 977,982 --- 981,990 } } + #endif /* FEAT_MBYTE || FEAT_OLE */ + + #if defined(FEAT_MBYTE) || defined(PROTO) + /* * Call WideCharToMultiByte() and allocate memory for the result. * Returns the result in "*out[*outlen]" with an extra NUL appended. -- Thanks a lot for the VIM Editor Greetings Mathias
VS2005 linking errors with FEATURES=TINY GUI=yes OLE=yes
Hi developers If I compile vim on Windows XP with Microsoft Visual Studio 2005 Express Edition on the command line with nmake -f Make_mvc.mak DEBUG=yes FEATURES=TINY GUI=yes OLE=yes I get the errors: ex_cmds2.obj : error LNK2019: unresolved external symbol _get_locale_val referenced in function _get_mess_env os_mswin.obj : error LNK2019: unresolved external symbol _gui_mch_dialog referenced in function _display_errors Is this a bug or isn't this configuration supported for certain reasons? Thanks for any replies! Best regards Mathias
Re: Vim on Windows XP x64
> Is someone working on integrating Microsoft Platform SDK / Visual > C++ 2005? > Yes, I do, and I already have sent some patches to this list. http://groups.yahoo.com/group/vimdev/message/43765 http://groups.yahoo.com/group/vimdev/message/43821 http://groups.yahoo.com/group/vimdev/message/43825 Please pay attention to them, I don't want to create them again. With kind regards Mathias
Patch: Make_mvc.mak can't handle path names that contain spaces
Patch
Problem:Make_mvc.mak can't handle path names that contain spaces.
Solution: Surround path names by quotes
Files: src/Make_mvc.mak
*** ..\vim-7.0.000\src\Make_mvc.mak 2006-05-31 09:13:13.607288000 +0200
--- src\Make_mvc.mak2006-05-31 10:24:17.718779200 +0200
***
*** 265,271
# you can get xpm.lib from http://iamphet.nm.ru/xpm or create it yourself
XPM_OBJ = $(OBJDIR)/xpm_w32.obj
XPM_DEFS = -DFEAT_XPM_W32
! XPM_LIB = $(XPM)\lib\libXpm.lib
XPM_INC = -I $(XPM)\include
!endif
!endif
--- 265,271
# you can get xpm.lib from http://iamphet.nm.ru/xpm or create it yourself
XPM_OBJ = $(OBJDIR)/xpm_w32.obj
XPM_DEFS = -DFEAT_XPM_W32
! XPM_LIB = "$(XPM)\lib\libXpm.lib"
XPM_INC = -I $(XPM)\include
!endif
!endif
***
*** 525,536
-DDYNAMIC_TCL_VER=\"$(TCL_VER_LONG)\"
TCL_OBJ = $(OUTDIR)\if_tcl.obj
TCL_INC = /I "$(TCL)\Include" /I "$(TCL)"
! TCL_LIB = $(TCL)\lib\tclstub$(TCL_VER).lib
!else
CFLAGS = $(CFLAGS) -DFEAT_TCL
TCL_OBJ = $(OUTDIR)\if_tcl.obj
TCL_INC = /I "$(TCL)\Include" /I "$(TCL)"
! TCL_LIB = $(TCL)\lib\tcl$(TCL_VER)vc.lib
!endif
!endif
--- 525,536
-DDYNAMIC_TCL_VER=\"$(TCL_VER_LONG)\"
TCL_OBJ = $(OUTDIR)\if_tcl.obj
TCL_INC = /I "$(TCL)\Include" /I "$(TCL)"
! TCL_LIB = "$(TCL)\lib\tclstub$(TCL_VER).lib"
!else
CFLAGS = $(CFLAGS) -DFEAT_TCL
TCL_OBJ = $(OUTDIR)\if_tcl.obj
TCL_INC = /I "$(TCL)\Include" /I "$(TCL)"
! TCL_LIB = "$(TCL)\lib\tcl$(TCL_VER)vc.lib"
!endif
!endif
***
*** 551,557
-DDYNAMIC_PYTHON_DLL=\"python$(PYTHON_VER).dll\"
PYTHON_LIB = /nodefaultlib:python$(PYTHON_VER).lib
!else
! PYTHON_LIB = $(PYTHON)\libs\python$(PYTHON_VER).lib
!endif
!endif
--- 551,557
-DDYNAMIC_PYTHON_DLL=\"python$(PYTHON_VER).dll\"
PYTHON_LIB = /nodefaultlib:python$(PYTHON_VER).lib
!else
! PYTHON_LIB = "$(PYTHON)\libs\python$(PYTHON_VER).lib"
!endif
!endif
***
*** 561,575
!ifndef MZSCHEME_VER
MZSCHEME_VER = 205_000
!endif
! CFLAGS = $(CFLAGS) -DFEAT_MZSCHEME -I $(MZSCHEME)\include
!if "$(DYNAMIC_MZSCHEME)" == "yes"
!message MzScheme DLLs will be loaded dynamically
CFLAGS = $(CFLAGS) -DDYNAMIC_MZSCHEME \
-DDYNAMIC_MZSCH_DLL=\"libmzsch$(MZSCHEME_VER).dll\" \
-DDYNAMIC_MZGC_DLL=\"libmzgc$(MZSCHEME_VER).dll\"
!else
! MZSCHEME_LIB = $(MZSCHEME)\lib\msvc\libmzgc$(MZSCHEME_VER).lib \
! $(MZSCHEME)\lib\msvc\libmzsch$(MZSCHEME_VER).lib
!endif
MZSCHEME_OBJ = $(OUTDIR)\if_mzsch.obj
!endif
--- 561,575
!ifndef MZSCHEME_VER
MZSCHEME_VER = 205_000
!endif
! CFLAGS = $(CFLAGS) -DFEAT_MZSCHEME -I "$(MZSCHEME)\include"
!if "$(DYNAMIC_MZSCHEME)" == "yes"
!message MzScheme DLLs will be loaded dynamically
CFLAGS = $(CFLAGS) -DDYNAMIC_MZSCHEME \
-DDYNAMIC_MZSCH_DLL=\"libmzsch$(MZSCHEME_VER).dll\" \
-DDYNAMIC_MZGC_DLL=\"libmzgc$(MZSCHEME_VER).dll\"
!else
! MZSCHEME_LIB = "$(MZSCHEME)\lib\msvc\libmzgc$(MZSCHEME_VER).lib" \
! "$(MZSCHEME)\lib\msvc\libmzsch$(MZSCHEME_VER).lib"
!endif
MZSCHEME_OBJ = $(OUTDIR)\if_mzsch.obj
!endif
***
*** 591,597
!endif
# Is Perl installed in architecture-specific directories?
! !if exist($(PERL)\Bin\MSWin32-x86)
PERL_ARCH = \MSWin32-x86
!endif
--- 591,597
!endif
# Is Perl installed in architecture-specific directories?
! !if exist("$(PERL)\Bin\MSWin32-x86")
PERL_ARCH = \MSWin32-x86
!endif
***
*** 599,608
# Version-dependent stuff
!if $(PERL_VER) == 55
! PERL_LIB = $(PERL_INCDIR)\perl.lib
!else
PERL_DLL = perl$(PERL_VER).dll
! PERL_LIB = $(PERL_INCDIR)\perl$(PERL_VER).lib
!endif
CFLAGS = $(CFLAGS) -DFEAT_PERL
--- 599,608
# Version-dependent stuff
!if $(PERL_VER) == 55
! PERL_LIB = "$(PERL_INCDIR)\perl.lib"
!else
PERL_DLL = perl$(PERL_VER).dll
! PERL_LIB = "$(PERL_INCDIR)\perl$(PERL_VER).lib"
!endif
CFLAGS = $(CFLAGS) -DFEAT_PERL
***
*** 613,623
!undef PERL_LIB
!endif
! PERL_EXE = $(PERL)\Bin$(PERL_ARCH)\perl
! PERL_INC = /I $(PERL_INCDIR)
PERL_OBJ = $(OUTDIR)\if_perl.obj $(OUTDIR)\if_perlsfio.obj
! XSUBPP = $(PERL)\lib\ExtUtils\xsubpp
! XSUBPP_TYPEMAP = $(PERL)\lib\ExtUtils\typemap
!endif
--- 613,623
!undef PERL_LIB
!endif
! PERL_EXE = "$(PERL)\Bin$(PERL_ARCH)\perl"
! PERL_INC = /I "$(PERL_INCDIR)"
PERL_OBJ = $(OUTDIR)\if_perl.obj $(OUTDIR)\if_perlsfio.obj
! XSUBPP = "$(PERL)\lib\ExtUtils\xsubpp"
! XSUBPP_TYPEMAP = "$(PERL)\lib\ExtUtils\typemap"
!endif
***
*** 653,659
CFLAGS = $(CFLAGS) -DFEAT_RUBY
RUBY_OBJ = $(OUTDIR)\if_ruby.obj
RUBY_INC = /I "$(RUBY)\lib\ruby\$(RUBY_VER_LONG)\$(RUBY_PLATFORM)"
! RUBY_LIB = $(RUBY)\lib\$(RUBY_INSTALL_NAME).lib
# Do we want to load Ruby dynamically?
!if "$(DYNAMIC_RUBY)" == "yes"
Patch: gvimext.dll don't find MSVCR80.dll when built with VC8. No context menu entries.
Patch 7.0.Make_GvimExt Problem:On Windows, when GvimExt is built with Microsoft Visual Studio 2005, the context menu item "Edit with vim" doesn't appear in Explorer. Reason: GvimExt.dll cannot be loaded, because it is not prepared to the Windows Side by Side Components subsystem and so cannot find the C Runtime library in MSVCR80.dll. Solution: A manifest file is created by the linker. Embed it into the resources of GvimExt.dll. Files: src/GvimExt/Makefile *** ..\vim-7.0.000\src\GvimExt\Makefile 2006-05-07 16:13:00.0 +0200 --- src\GvimExt\Makefile2006-05-30 14:42:37.168430400 +0200 *** *** 19,24 --- 19,25 # $(implib) /NOLOGO -machine:$(CPU) -def:gvimext.def $** -out:gvimext.lib # $(link) $(dlllflags) -base:0x1C00 -out:$*.dll $** $(olelibsdll) shell32.lib gvimext.lib comctl32.lib gvimext.exp $(link) $(lflags) -dll -def:gvimext.def -base:0x1C00 -out:$*.dll $** $(olelibsdll) shell32.lib comctl32.lib + if exist $*.dll.manifest mt -nologo -manifest $*.dll.manifest -outputresource:$*.dll;2 gvimext.obj: gvimext.h *** *** 34,36 --- 35,38 - if exist gvimext.exp del gvimext.exp - if exist gvimext.obj del gvimext.obj - if exist gvimext.res del gvimext.res + - if exist gvimext.dll.manifest del gvimext.dll.manifest -- Thanks a lot for the GvimExt project for Windows! I appreciate it very much. Greetings Mathias
Re: Runtime error in explorer.exe when right clicking with vim70f gvimext.dll installed
Ilya first of all: THANKS! > This issue is explained in MSDN in section about SxS - Side by > Side Components. I've attached patch against current > GvimExt/gvimext.rc that would make resource compiler add manifest > inside generated DLL - this is what is required to make it run on > WinXP SP2 and Win2k3. > I first tried your patch, but then the resource compiler complained he couldn't find a file named "winres.h". I then restored the original files, applied the following patch to your patch, and then applied your patch again. This was a full success! The dll now worked! The patch that I had to apply to your patch was: Change the names winres.h <--> winresrc.h: *** gvimext.rc.patch.orig 2006-05-30 14:34:24.269676800 +0200 --- gvimext.rc.patch2006-05-30 13:46:16.937897600 +0200 *** *** 15,19 + #if defined(__BORLANDC__) || defined(__CYGWIN32__) || defined(__MINGW32__) - + # include - + #else + # include + #endif --- 15,19 + #if defined(__BORLANDC__) || defined(__CYGWIN32__) || defined(__MINGW32__) + # include + + #else + + # include + #endif But in spite of this success, I was not yet fully satisfied. (Yes, I know, I have high demands): The linker itself creates a gvimext.dll.manifest file, and I would like to use that one, but only if it is present. Now, thank to your hint, I now that embedding the manifest into the resources of a dll is THE solution! Therefore, I restored the code to its original state (without applying any patches). >> Then I tried >> >> mt -outputresource:gvimext.dll -manifest gvimext.dll.manifest >> >> to include the dll into the resources of gvimext.dll. That helped >> nothing. >> > To include the manifest as a resource into the dll? I don't know > exactly why this was not working for you. > Because it was not the right command -- but it was almost right. Today, I tried (again without you patch): mt -manifest gvimext.dll.manifest -outputresource:gvimext.dll;2 This worked again! Now I am happy because it is enough to add only one single line to the original Makefile in order to make it work also for the new version of the Microsoft Visual Studio: if exist gvimext.dll.manifest do "the above command". > This issue is explained in MSDN in section about SxS - Side by > Side Components. > Thanks again! That leaded me to the correct command: http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx With best regards Mathias Michaelis
Re: Runtime error in explorer.exe when right clicking with vim70f gvimext.dll installed
Hello Vim List I have a similar problem with the final vim 7.0, if I try to compile it with Microsoft Visual Studio 2005 Express Edition. I don't get a runtime error, but simply get no "Edit with vim ..." context menu entries when I right-click on any file. >>> When I right click on a file in explorer I get an MSVC Runtime error >>> dialog: >>> >> msvcr80.dll is the problem, but it isn't that the dll is missing, >> gvimext.dll loads it from c:\windows\system32. The problem is that >> gvimext.dll is loading the dll incorrectly (according to the error >> dialog). Obviously the source for gvimext.dll hasn't changed in a >> while, but I believe this means that the gvimext.dll can't be built >> against VC 8.0 until this problem is resolved. :/ >> > Try copying src\GvimExt\gvimext.dll.manifest to wherever you've placed > gvimext.dll. > This was the first thing I tried. Then I checked with "Dependency Walker" and saw that MSVCR80.DLL was now found. But in spite of that: I got no context menus. Then I tried mt -outputresource:gvimext.dll -manifest gvimext.dll.manifest to include the dll into the resources of gvimext.dll. That helped nothing. Then I tried to add a session to gvimext.dll.manifest: Helped nothing, independent of running mt.exe or not. I am searching for solutions for days now, browsed all the msdn library, but found nothing: gvimext.dll doesn't work when linked against MSVCR80.DLL with Visual Studio 2005 Express Edition. The only workaround is: I have to link gvimext.dll statically against the C runtime library. Then, gvimext.dll needs about five times more space on disk, but like that the context menu entries appear although I hardly can't believe it any more %-] Thanks in advance for any suggestions or hints! With best regards Mathias
PC sources lacks if_sniff.c
Hi vimmers! The source archive ftp://ftp.vim.org/pub/vim/pc/vim70src.zip contains the file if_sniff.h but not the corresponding source file if_sniff.c. Has this a specific reason or has if_sniff.c simply been forgotten? With kind regards Mathias
Patch: Make_mvc.mak creates an empty gvim.exe.mnf file
Patch Problem:Make_mvc.mak creates an empty gvim.exe.mnf file (or stops with an error message). (Suresh Govindachar) Solution: Don't use 'echo' to create files. Use inline files instead. Files: src/Make_mvc.mak *** ..\vim-7.0.000\src\Make_mvc.mak 2006-05-07 16:13:02.0 +0200 --- src\Make_mvc.mak2006-05-22 22:11:29.768449600 +0200 *** *** 963,1001 E_CFLAGS = $(E0_CFLAGS:"=\") $(PATHDEF_SRC): auto ! @echo creating $(PATHDEF_SRC) ! @echo /* pathdef.c */ > $(PATHDEF_SRC) ! @echo #include "vim.h" >> $(PATHDEF_SRC) ! @echo char_u *default_vim_dir = (char_u *)"$(VIMRCLOC:\=\\)"; >> $(PATHDEF_SRC) ! @echo char_u *default_vimruntime_dir = (char_u *)"$(VIMRUNTIMEDIR:\=\\)"; >> $(PATHDEF_SRC) ! @echo char_u *all_cflags = (char_u *)"$(CC:\=\\) $(E_CFLAGS)"; >> $(PATHDEF_SRC) ! @echo char_u *all_lflags = (char_u *)"$(link:\=\\) $(LINKARGS1:\=\\) $(LINKARGS2:\=\\)"; >> $(PATHDEF_SRC) ! @echo char_u *compiled_user = (char_u *)"$(USERNAME)"; >> $(PATHDEF_SRC) ! @echo char_u *compiled_sys = (char_u *)"$(USERDOMAIN)"; >> $(PATHDEF_SRC) gvim.exe.mnf: auto ! @echo ^ >$@ ! @echo ^ >>$@ ! @echo ^>$@ ! @echo processorArchitecture="$(ASSEMBLY_ARCHITECTURE)" >>$@ ! @echo version="7.0.0.0" >>$@ ! @echo type="win32" >>$@ ! @echo name="Vim" >>$@ ! @echo /^> >>$@ ! @echo ^Vi Improved - A Text Editor^ >>$@ ! @echo ^ >>$@ ! @echo ^ >>$@ ! @echo ^>$@ ! @echo type="win32" >>$@ ! @echo name="Microsoft.Windows.Common-Controls" >>$@ ! @echo version="6.0.0.0" >>$@ ! @echo publicKeyToken="6595b64144ccf1df" >>$@ ! @echo language="*" >>$@ ! @echo processorArchitecture="$(ASSEMBLY_ARCHITECTURE)" >>$@ ! @echo /^> >>$@ ! @echo ^ >>$@ ! @echo ^ >>$@ ! @echo ^ >>$@ auto: if not exist auto/nul mkdir auto --- 963,1005 E_CFLAGS = $(E0_CFLAGS:"=\") $(PATHDEF_SRC): auto ! @echo creating $@ ! @copy << $@ ! /* pathdef.c */ ! #include "vim.h" ! char_u *default_vim_dir = (char_u *)"$(VIMRCLOC:\=\\)"; ! char_u *default_vimruntime_dir = (char_u *)"$(VIMRUNTIMEDIR:\=\\)"; ! char_u *all_cflags = (char_u *)"$(CC:\=\\) $(E_CFLAGS)"; ! char_u *all_lflags = (char_u *)"$(link:\=\\) $(LINKARGS1:\=\\) $(LINKARGS2:\=\\)"; ! char_u *compiled_user = (char_u *)"$(USERNAME)"; ! char_u *compiled_sys = (char_u *)"$(USERDOMAIN)"; ! << gvim.exe.mnf: auto ! @copy << $@ ! ! ! ! Vi Improved - A Text Editor ! ! ! ! ! ! ! << auto: if not exist auto/nul mkdir auto -- Thanks a lot for the VIM Editor! Greetings Mathias
