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: 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
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
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 ifs. 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 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 ifs.
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::
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: 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...
Re: vim | editing pdf files with vim
Nikolaos A. Patsopoulos did utter on 10/10/2006 14:58: Hi all, is there a way to edit pdf files with vim? If not pdf as is, then eps or postscript? I tried with either format but the text kept been converted to sthl ike ASCII code. In general trying to edit PDF or PostScript files is a non-starter, unless you have a lot of knowledge about how the files were constructed. In particular, text depends on the font encoding used. It will be much easier to go back to the original application that generated the PDF/PS and edit the document there. TTFN Mike -- Free the bound periodicals!
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
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: 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: Printing with linebreak
Java Bob did utter on 22/06/2006 15:00: Thanks Jürgen, but your reply does not help. Your solution :set printoptions+=wrap:y is equivalent to :set wrap I am still looking for something like :set linebreak The problem is th at my words are b eing wrapped in t heir middle!!! hardcopy does not do linebreak. It is on the todo list I believe. Mike -- Ghosts love music - especially haunting melodies!
Re: how to detect c99 vs c89 (//-comments vs /*-comments)
Hi, In general you cannot detect which version of the standard some C has been written against since C89 code should still compile with a C99 compiler. There are new keywords, but some developers use macros to emulate C99 like features in C89 code. Your best bet is a mode line, possible a good ol' human one as a comment at the top of the file - /* This file developed against C99/C89 [delete as applicable] */ - so that the code is self documenting, and it can be picked up by VIM on loading to set whatever settings you want. shameless_self_promotion While not helping with detecting whether C source is C89 or C99, my alternate C syntax file helps with developing portable C for a particular C standard. http://www.vim.org/scripts/script.php?script_id=234 /shameless_self_promotion TTFN Mike -- Pulse not found: (A)bandon hope, (R)eincarnate, or (I)gnore?
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.
