Re: Cannot print in UTF-8?
On 18/05/2007 03:31, A.J.Mechelynck wrote: :set enc? penc? encoding=utf-8 printencoding=utf-8 :%ha not found in runtimepath: print/utf-8.ps Is this last message normal? Yes. I have here a file including an Esperanto-French glossary, which contains both the consonants+circumflex of Esperanto and the French oe ligature. No matter how I try, Vim cannot print it: - penc=utf-8 gives the above error - penc=latin3 prints Esperanto correctly, but oe becomes an inverted question mark - penc=latin9 prints French correctly but not the Esperanto letters. Compiled with +multi_byte +iconv +printer +postscript Looks like the only way to print that file properly is to load it in my browser. Unicode encoding is only supported for CJK fonts at the moment. Of course, if you had such a font with the glyphs you want, then this will work. TTFN Mike -- The Buck stops here; the Doe just visits.
Re: C syntax problem with C99 initializers.
On 19/03/2007 17:39, David Brown wrote:
Martin Krischik wrote:
Am Montag 19 März 2007 schrieb David Brown:
A macro like this:
#define FOO ((fooy) { field: 4 })
Whenever I thougth I saw it all C comes with another suprise. What
the heck is this good for?
It is a constant structure, useful, in this case, as a macro to
indicate a constant value. The "field:" thing is gcc, the proper C99
syntax is:
{ .field = 4 }
But what is confusing vim is the braces inside of the parens. As Bram
mentioned in another email, this can be disabled, but it makes vim not
able to detect unclosed parens.
Have you tried the alternate C syntax highlight file here?
http://www.vim.org/scripts/script.php?script_id=234
TTFN
Mike
--
At least the doctors find me fascinating.
Re: Win64-related patches
On 12/02/2007 07:48, George V. Reilly wrote: * Win64 changes to make code compile cleanly: eval.c, misc2.c, if_ole.* * Fixed install.exe bug * Fixed annoying warning from Explorer about gvimext.dll * Fixed gvim.exe.mnf to be cross-platform. No longer needs to be generated from Make_mvc.mak * Re-fixed spell.c so that it works with VC6. Unit tests go into an infinite loop otherwise. * Updated INSTALLpc.txt to reflect that Visual C++ 2005 Express Edition is now free forever, recommending it over the VC 2003 Toolkit. * Cleaned up Make_mvc.mak, incorporating (and fixing) recent patches from Alexei Alexandrov and Mike Williams Last week's service pack for VS2005 has changed the nmake version number. It just needs the following three lines adding after the ones for the previous version for VS2005. !if "$(_NMAKE_VER)" == "8.00.50727.762" MSVCVER = "8.0" !endif I also had to edit make_mvc.mak for tests of MSVCVER as nmake did not like it enclosed in quotes. The expressions had to be of the form !if $(MSVCVER) == ... Since MSVCVER is set to a string the extra quotes end up being double double quotes which is invalid syntax. Should MSVCVER be set to string in the makefile? What do they come through as from the platform SDK? Apart from that all seems to work as expected. * Added mkdist.bat to copy all of the installable files to vim70 directory, where they are zipped up, for later installation on Win64 or Win32. * Made a futile attempt to get gvim.nsi building. Just building. Never mind running on Win64. * Fixed a bug in test60: test60.ok must have Unix line endings I have tested this code with the VS 98 (VC6), VS .NET 2003 (VC 7.1), VS 2003 Toolkit (VC 7.1), Visual Studio 2005 (VC8), Visual Studio 2005 Express Edition (VC 8), and the VS 2005 x64 cross-compiler. I'll re-test the Win64 binaries on a borrowed AMD64 machine at work tomorrow. As of yesterday, I was able to use install.exe to successfully install gvim and register gvimext.dll, giving the Edit with Vim entry in the Explorer context menu. Once everything is retested, I'll make fresh Win64 binaries available. One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim -register', and watch it crash while trying to display an error message. Mike -- Sometimes a majority means that all the fools are on one side.
Re: Patch for Make_mvc.mak
On 08/02/2007 19:27, Alexei Alexandrov wrote: Hi All! Here is a patch for make_mvc.mak file which is used to build Vim on Windows. The changes are the following: 1. I had to add "!undef NODEBUG" in one place to make debug configuration working as needed. Before this change the debug configuration did the same as release. 2. /ZI (not /Zi) should be used in debug configuration. /ZI creates much more useful PDB - with just /Zi you will not be able to look at the values of variables which are currently in registers. Because of adding /ZI I had to remove /incremental:no from linker flags (don't know exact implications of this - probably it's good idea to still have it in release configuration). Removing incremental:no will result in a larger executable due to the linker adding padding. A quick check shows removing this option has no effect so it looks like it had no effect in the first place. It is moot whether distributing executables with debug information is useful - for VC builds, without the .pdb file (and the source in the right place) it is pretty useless. 3. I removed /nodefaultlib switch whenever possible. Having it is a bad idea by itself - often indicates a dangerous CRT mix. I removed /nodefaultlib to support Intel Compiler, in fact. Now I can use just command nmake -f Make_mvc.mak ... CC=icl to compile Vim with Intel Compiler. With /nodefaultlib it won't work, because Intel Compiler adds to object files information about additonal static library which executable need to link with. Of course, it can be solved by checking "if it's Intel Compiler then link with this addditional library", but avoiding /nodefaultlib is a good idea anyway. There is a possible issue with VC8 if VIM is linked against any libraries that require libc.lib - this is no longer part of VC8 builds and will cause a problem. However, VIM does not seem to currently link against any such libraries (or at least the couple of builds I do) so it seems ok to remove. Mike -- Don't worry about temptation - as you grow older, it starts avoiding you.
Re: VC8 makefile patch
Oops, the last diff was wrong. Please try this one.
TTFN
Mike
--
INNEWATOK INquiring NErd WAnts TO Know
*** Make_mvc.mak.orig Wed Apr 26 10:30:22 2006
--- Make_mvc.makMon Jan 22 14:07:52 2007
***
*** 92,97
--- 92,99
# Netbeans Debugging Support: NBDEBUG=[yes or no] (should be no, yes
# doesn't work)
#
+ # Visual C Version: MSVCVER=m.n (default derived from nmake if
undefined)
+ #
# You can combine any of these interfaces
#
# Example: To build the non-debug, GUI version with Perl interface:
***
*** 320,326
--- 322,362
INTDIR=$(OBJDIR)
OUTDIR=$(OBJDIR)
+ # Derive version of VC being used from nmake if not specified
+ !if "$(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.10.3077"
+ MSVCVER = "7.1"
+ !endif
+ !if "$(_NMAKE_VER)" == "8.00.50727.42"
+ MSVCVER = "8.0"
+ !endif
+ !endif
+
+ # Abort bulding VIM if version of VC is unrecognised.
+ !ifndef MSVCVER
+ !message *** ERROR
+ !message Cannot determine Visual C version being used. If you are using the
+ !message Windows SDK then you must have the environment variable MSVCVER set
to
+ !message your version of the VC compiler. If you are not using the Express
+ !message version of Visual C you van either set MSVCVER or update this
makefile
+ !message to handle the new value for _NMAKE_VER.
+ !error Make aborted.
+ !endif
+
# Convert processor ID to MVC-compatible number
+ !if $(MSVCVER) != "8.0"
!if "$(CPUNR)" == "i386"
CPUARG = /G3
!elseif "$(CPUNR)" == "i486"
***
*** 334,339
--- 370,381
!else
CPUARG =
!endif
+ !else
+ # VC8 only allows specifying SSE architecture
+ !if "$(CPUNR)" == "pentium4"
+ CPUARG = /arch:SSE2
+ !endif
+ !endif
!ifdef NODEBUG
VIM = vim
***
*** 344,349
--- 386,397
!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
--- 411,417
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
--- 755,769
$(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::
--- 852,858
# 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::
--- 861,867
# 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 again,
Attached is a new version of the VC makefile that uses MSVCVER if
defined or derives a value from nmake. This should allow the file to be
used straight from a source download without any environment variables
having to be set.
If anyone has other values for _NMAKE_VER (just run nmake with no args
and it will be on the first line where the MS version is reported), can
they report them along with which version (and any service packs
applied) of VC they are using.
Enjoy.
Mike
--
Computer malfunction, nut loose in operator's chair.
*** Make_mvc.mak.orig Wed Apr 26 10:30:22 2006
--- Make_mvc.makMon Jan 22 13:59:43 2007
***
*** 92,97
--- 92,99
# Netbeans Debugging Support: NBDEBUG=[yes or no] (should be no, yes
# doesn't work)
#
+ # Visual C Version: MSVCVER=m.n (default derived from nmake if
undefined)
+ #
# You can combine any of these interfaces
#
# Example: To build the non-debug, GUI version with Perl interface:
***
*** 320,326
--- 322,362
INTDIR=$(OBJDIR)
OUTDIR=$(OBJDIR)
+ # Derive version of VC being used from nmake if not specified
+ !if "$(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.10.3077"
+ MSVCVER = "7.1"
+ !endif
+ !if "$(_NMAKE_VER)" == "8.00.50727.42"
+ MSVCVER = "8.0"
+ !endif
+ !endif
+
+ # Abort bulding VIM if version of VC is unrecognised.
+ !ifndef MSVCVER
+ !message *** ERROR
+ !message Cannot determine Visual C version being used. If you are using the
+ !message Windows SDK then you must have the environment variable MSVCVER set
to
+ !message your version of the VC compiler. If you are not using the Express
+ !message version of Visual C you van either set MSVCVER or update this
makefile
+ !message to handle the new value for _NMAKE_VER.
+ !error Make aborted.
+ !endif
+
# Convert processor ID to MVC-compatible number
+ !if "$(MSVCVER)" != "8.0"
!if "$(CPUNR)" == "i386"
CPUARG = /G3
!elseif "$(CPUNR)" == "i486"
***
*** 334,339
--- 370,381
!else
CPUARG =
!endif
+ !else
+ # VC8 only allows specifying SSE architecture
+ !if "$(CPUNR)" == "pentium4"
+ CPUARG = /arch:SSE2
+ !endif
+ !endif
!ifdef NODEBUG
VIM = vim
***
*** 344,349
--- 386,397
!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
--- 411,417
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
--- 755,769
$(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::
--- 852,858
# 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::
--- 861,867
# 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 Mathias. On 20/01/2007 11:48, Mathias Michaelis wrote: 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. I didn't think the Express version of the compilers supported optimized code generation. And I am surprised VCExpress comes without nmake. > 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. Ah, that would be a problem. 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. 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? 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. I was afraid this might happen. 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. Indeed there was. I think its _NMAKE_VER value is 7.10.3077. 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?). 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. 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? Best regards and thanks again for this patch No problems. As ever, every new solution generates new problems. Mike -- Don't pick up that pho+>+Abe+++f NO CARRIER
Re: VC8 makefile patch
On 18/01/2007 20:55, Bram Moolenaar wrote: Mike Williams wrote: Attached is a patch to use VC8 specific optimization options. FTR, VC8 no longer supports the /Gn processor code generation directive, and the makefile now uses link time code generation when not optimizing for space. Although MS keeps changing the arguments, the new ones mostly get used again in future versions. Thus this check: + !if "$(_NMAKE_VER)" != "8.00.50727.42" Should probably check if the version is greater than or smaller than this specific number. At least do the comparing with this specific number once and pass the result to further "if"s. Proposal #2 - now derives VC version from _NMAKE_VER. Updated a couple of checks for VC4 so the file is a bit more more self documenting. Thanks, looks much better. I wonder what "<" actually does. Is it a textual compare? Perhaps you can try out if using ">" or "<" works to avoid these magic build numbers. Some people must have different builds (otherwise they wouldn't include these numbers, right?). The doc states that strings should be compared with == and != but empirically (at least with VC8 ;-) ) the ordering relational operators seem to work. It is possible they don't in older versions, in which case they would need to be the equality operators only. Perhaps those with VC4/5/6/7 can try out the patch and see if it works or not. The numbers identify specific versions of VC. I believe early releases (MS's CTP, public betas etc.) have different numbers but I cannot find any reference list to discern a definitive pattern. HTH Mike -- If you're trying to drive me crazy, you're too late!
Re: VC8 makefile patch
On 18/01/2007 15:50, A.J.Mechelynck wrote: Mike Williams wrote: On 17/01/2007 19:44, Bram Moolenaar wrote: Mike Williams wrote: Attached is a patch to use VC8 specific optimization options. FTR, VC8 no longer supports the /Gn processor code generation directive, and the makefile now uses link time code generation when not optimizing for space. Although MS keeps changing the arguments, the new ones mostly get used again in future versions. Thus this check: + !if "$(_NMAKE_VER)" != "8.00.50727.42" Should probably check if the version is greater than or smaller than this specific number. At least do the comparing with this specific number once and pass the result to further "if"s. Proposal #2 - now derives VC version from _NMAKE_VER. Updated a couple of checks for VC4 so the file is a bit more more self documenting. Enjoy. Mike ...sorry, my mailer shows the patches inline but doesn't quote them on reply. Rather than testing for specific strings, couldn't you just use the first digit(s) of _NMAKE_VER as the "version number" if followed by a period? Or doesn't the make evaluation syntax allow for that? I don't believe it does, but I am not a nmake maven. I believe VC service packs update the nmake version numbers, so something like vc7 service pack 1 would be 7.10..nn (where is a build number I think - but could well be wrong). A google does not turn up a reference list of nmake version numbers for various VC releases and service packs. The numbers I have used are the only ones I have managed to cobble together. > (I suppose if someday the version string becomes, let's say, 9.05.77643.25 we should take this as meaning "version 9" rather than default to "version 6" don't you think?) I chose 6 to be controversial. It does not always pay to assume the latest and greatest - there are still a large number of developers using older VC versions for various reasons. Perhaps it would be better to error out for unknown VC versions so the first person to use it fixes up the make file as required. Something like: # Abort bulding vim if version of VC is unrecognised. !ifndef VC_VER !message *** NOTE !message Cannot detect version of Visual C being used. Please update !message the makefile for the version of Visual C you are using. !error Make aborted. !endif TTFN Mike -- Where can I find a spell chequer for taglines?
Re: VC8 makefile patch
On 17/01/2007 19:44, Bram Moolenaar wrote:
Mike Williams wrote:
Attached is a patch to use VC8 specific optimization options. FTR, VC8
no longer supports the /Gn processor code generation directive, and the
makefile now uses link time code generation when not optimizing for space.
Although MS keeps changing the arguments, the new ones mostly get used
again in future versions. Thus this check:
+ !if "$(_NMAKE_VER)" != "8.00.50727.42"
Should probably check if the version is greater than or smaller than
this specific number. At least do the comparing with this specific
number once and pass the result to further "if"s.
Proposal #2 - now derives VC version from _NMAKE_VER. Updated a couple
of checks for VC4 so the file is a bit more more self documenting.
Enjoy.
Mike
--
Barnum was wrong... it's more like every thirty seconds.
*** Make_mvc.mak.orig Wed Apr 26 10:30:22 2006
--- Make_mvc.makThu Jan 18 11:07:26 2007
***
*** 320,326
--- 320,348
INTDIR=$(OBJDIR)
OUTDIR=$(OBJDIR)
+ # Derive version of VC being used
+ !if "$(_NMAKE_VER)" == ""
+ VC_VER = 4
+ !endif
+ !if "$(_NMAKE_VER)" == "162"
+ VC_VER = 5
+ !endif
+ !if "$(_NMAKE_VER)" == "6.00.8168.0"
+ VC_VER = 6
+ !endif
+ !if "$(_NMAKE_VER)" == "7.00.9466"
+ VC_VER = 7
+ !endif
+ !if "$(_NMAKE_VER)" == "8.00.50727.42"
+ VC_VER = 8
+ !endif
+ # Default to VC6 (arbitrarily) if unknown
+ !ifndef VC_VER
+ VC_VER = 6
+ !endif
+
# Convert processor ID to MVC-compatible number
+ !if "$(VC_VER)" < "8"
!if "$(CPUNR)" == "i386"
CPUARG = /G3
!elseif "$(CPUNR)" == "i486"
***
*** 334,339
--- 356,367
!else
CPUARG =
!endif
+ !else
+ # VC8 only allows specifying SSE architecture
+ !if "$(CPUNR)" == "pentium4"
+ CPUARG = /arch:SSE2
+ !endif
+ !endif
!ifdef NODEBUG
VIM = vim
***
*** 344,349
--- 372,383
!else # MAXSPEED
OPTFLAG = /Ox
!endif
+ !if "$(VC_VER)" >= "8"
+ # 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
--- 397,403
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 "$(VC_VER)" == "4"
LIBC =
! else
LIBC = /fixed:no
***
*** 707,712
--- 741,755
$(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 "$(VC_VER)" >= "8"
+ !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::
--- 838,844
# 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 "$(VC_VER)" == "4"
.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::
--- 847,853
# 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 "$(VC_VER)" == "4"
.cpp{$(OUTDIR)/}.obj:
!ELSE
.cpp{$(OUTDIR)/}.obj::
Re: VC8 makefile patch
On 17/01/2007 15:09, A.J.Mechelynck wrote: Mike Williams wrote: Hi, Attached is a patch to use VC8 specific optimization options. FTR, VC8 no longer supports the /Gn processor code generation directive, and the makefile now uses link time code generation when not optimizing for space. Enjoy. Mike Why the test on "!if "$(_NMAKE_VER)" == "8.00.50727.42" ? Are you sure the old behaviour will be the right thing to do with _any_ older _or_ newer version? Shouldn't we rather assume that versions 8.0 "or later" of MSVC will require the new arguments? We should provide as best as we can for future versions, to avoid, if possible, the need for constant re-patching of the makefile with every new version that Gates & Co will decide to publish. The comparison operators can be made relative if desired. It is normal for any new VC compiler to review compiler options and update any build scripts. VC8 retired, deprecated, and added a large number of compiler/linker options. There is nothing to say future versions wont do the same. To have a build script use minimal options for an unrecognised compiler version is reasonable - as long as it reports that this is the case. Mike -- Do you think that you're right and I'm wrong? How naive if you do...
VC8 makefile patch
Hi, Attached is a patch to use VC8 specific optimization options. FTR, VC8 no longer supports the /Gn processor code generation directive, and the makefile now uses link time code generation when not optimizing for space. Enjoy. Mike -- If space is a vacuum, who changes the bags? *** Make_mvc.mak.orig Wed Apr 26 10:30:22 2006 --- Make_mvc.makWed Jan 17 13:48:57 2007 *** *** 321,326 --- 321,327 OUTDIR=$(OBJDIR) # Convert processor ID to MVC-compatible number + !if "$(_NMAKE_VER)" != "8.00.50727.42" !if "$(CPUNR)" == "i386" CPUARG = /G3 !elseif "$(CPUNR)" == "i486" *** *** 334,339 --- 335,346 !else CPUARG = !endif + !else + # VC8 only allows specifying SSE architecture + !if "$(CPUNR)" == "pentium4" + CPUARG = /arch:SSE2 + !endif + !endif !ifdef NODEBUG VIM = vim *** *** 344,349 --- 351,362 !else # MAXSPEED OPTFLAG = /Ox !endif + # Use link time code generation in VC8 if not worried about size + !if "$(_NMAKE_VER)" == "8.00.50727.42" + !if "$(OPTIMIZE)" != "SPACE" + OPTFLAG = $(OPTFLAG) /GL + !endif + !endif CFLAGS = $(CFLAGS) $(OPTFLAG) -DNDEBUG $(CPUARG) RCFLAGS = $(rcflags) $(rcvars) -DNDEBUG ! ifdef USE_MSVCRT *** *** 706,711 --- 719,733 LINKARGS2 = $(CON_LIB) $(GUI_LIB) $(LIBC) $(OLE_LIB) user32.lib $(SNIFF_LIB) \ $(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 "$(_NMAKE_VER)" == "8.00.50727.42" + !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
Re: Possible addition to the c.vim and perl.vim syntax files
mwoehlke did utter on 11/09/2006 18:37: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive="TRUE"', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. Mea culpa, you are right. Add an ll to the above list. What are not valid is lul. TTFN Mike -- Sign at Proctologist's office: "Parking in Rear"
Re: Possible addition to the c.vim and perl.vim syntax files
mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: Mark Manning wrote: I saw in the c.vim that there was an error statement for octal numbers. There isn't one for hex numbers so I made one really quickly. If you want, just put it into the c.vim file. :-) The test: syn regioncHexErrorstart="0x\x*[g-zG-Z]" end="\W" The highlight command: hi link cHexError cError Of course, this needs to be approved by Bram first though. :-) I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. Mike -- I made that part of the program bullet proof, but not 2x4 proof!
Re: Possible addition to the c.vim and perl.vim syntax files
Mark Manning did utter on 10/09/2006 23:52: I saw in the c.vim that there was an error statement for octal numbers. There isn't one for hex numbers so I made one really quickly. If you want, just put it into the c.vim file. :-) The test: syn regioncHexErrorstart="0x\x*[g-zG-Z]" end="\W" Two issues - you most likely want to add underscore to the range since it should be \w less the valid hex digits (the difference between 0x88_65 and 0x88-65 will then highlight), and you need to be able to allow for the unsigned and long integer suffixes are part of the hex value, e.g. 0x88ul The highlight command: hi link cHexError cError Of course, this needs to be approved by Bram first though. :-) TTFN Mike -- I am Homer of Borg! Prepare to be... Ooo! Donuts!
Re: SVN and svn:eol-style
Edward L. Fox did utter on 11/05/2006 06:45: On 5/11/06, Bill McCarthy <[EMAIL PROTECTED]> wrote: On Wed 10-May-06 9:43pm -0600, Anduin Withers wrote: >> Why do you want CR-LF files? A single LF should work just fine. The >> only place where I know it doesn't work is when you read Make_ivc.mak >> into Visual Studio. >> >> Automatic LF to CR-LF translation always causes trouble somewhere. > > CVS did it automatically, as long as binaries are properly tagged there > shouldn't be (and wasn't, at least for me) a problem. > > One reason is consistency: This is the behavior CVS had, it is the format > the releases are in on the ftp site, it also makes things look better when I > edit my .vim files with notepad. > > Just another request for native line endings. Some days it is better for me to read my mail from newest to oldest - or at least read through everything before replying. Well stated. I now wish I used a different example that notepad - although that is indeed a good one, since every Windows user has it and it is frequently a default in Explorer. Hopefully, the gentleman maintaining the svn repository (Edward L Fox) will talk to the gentleman who properly marked the files in CVS. Well, well, well... I prop-setted most of the file that I recognized. If you find anything wrong or prop missing, plz contact me. The bad news for everyone is, after prop-setting the files, everyone has to download the prop-setted files again. That will cost quite a long time. I have also had no problems with the CVS distribution That's because CVS doens't support that features at all and every text file is forced to use native linebreaks. -- Best regards, Bill Another match on the oil - the patch utility I use on windows gets very unhappy if the source file and patch file use different line endings. There isn't an option to alter line endings when saving attachments in TBird (that I have found). Fighting the natural order of things on a particular platform is a recipe for unending pain. I would have thought any source control system would Do The Right Thing wrt line endings by default, since the vast majority of files it will contain would be text based. 2ps worth. Mike -- Taglines temporarily suspended - sorry.
Re: Vim 70 and multibyte printing
Valery Kondakoff did utter on 13/04/2006 21:20: Hello, Yegappan! Thursday, April 13, 2006, 10:42:31 PM, you wrote: At least all my experiments were unsuccsessfull. I'm using gVim 7.0d under WinXP SP2. YL> According to version7.txt, multi-byte printing is now supported: YL> Printing multi-byte text *new-print-multi-byte* YL> -- YL> The |:hardcopy| command now supports printing multi-byte characters. YL> The 'printmbcharset' and 'printmbfont' options are used for this. YL> Also see |postscript-cjk-printing|. (Mike Williams) As you can see in my initial message I was trying to play with the new 'printmbcharset' and 'printmbfont' options, but I was unable to force gVim to print the file in correct encoding. So I was asking for some help: if there is some happy gVim 7.0 user, who set 'encoding' to 'utf-8' and still was able to print multibyte text? Can you, please, share your encoding-related settings? The multi-byte printing support was only for PostScript printing from VIM. I don't believe there is support for multi-byte printing using Windows printing yet. The conversion from the buffer encodinf to the print encoding has not yet been added to VIM. Mike -- Taglines temporarily suspended - sorry.
