Re: Cannot print in UTF-8?

2007-05-18 Thread Mike Williams

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.

2007-03-19 Thread Mike Williams

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

2007-02-20 Thread Mike Williams

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

2007-02-09 Thread Mike Williams

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

2007-01-22 Thread Mike Williams

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

2007-01-22 Thread Mike Williams

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

2007-01-22 Thread Mike Williams

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

2007-01-19 Thread Mike Williams

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

2007-01-19 Thread Mike Williams

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

2007-01-18 Thread Mike Williams

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

2007-01-17 Thread Mike Williams

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

2007-01-17 Thread Mike Williams

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

2006-09-12 Thread Mike Williams

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

2006-09-11 Thread Mike Williams

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

2006-09-11 Thread Mike Williams

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

2006-05-11 Thread Mike Williams

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

2006-04-19 Thread Mike Williams

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.