Re: BOF Vim 8 - EncryptLine
Robert Lee wrote: What is wrong with SCP/SFTP? If these are not available, externally encrypt the file. You can even make a vim macro to do the job IIRC. Text editors don't do encryption and never should. I promise to stop posting when everyone else does! SCP etc just encrypts the traffic when copying a sensitive file to another machine. After backups are taken and stored, and various other stuff happens, your sensitive file can end up in quite a lot of places. Defence-in-depth means you have to encrypt the actual secret (the file, or the secret parts of the file). As Tony pointed out, Vim can encrypt a file. That is good because if you rely on scripts and what-have-you, there can be temp files, and files left over when something crashes. It's much better if Vim handles the decryption and encryption for you - much more convenient, and reliable, and a lot more secure. I can see that my EncryptLine proposal doesn't have any support. Fair enough - I accept the judgement. But the idea is not stupid. When you document tricky stuff on a network, you end up with a file where normal file-access security is good enough to protect 95% of the content. What about the passwords in the document? You really need to encrypt the file to protect them, but that means you have to decrypt the file (enter its key) everytime you need to extract some fact (like an IP address). I have actually implemented my EncryptLine on an obsolete editor and it works really well - but only because I have a need for it. John
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: Problems with AutoIndenting comment lines in VHDL files
David le Comte wrote: This is my 2nd attempt, but with smaller sample vhdl file, The mail handler rejected my last email due to its being too large. Problem Description: When editing VHDL files, autoindent mode does not behave as expected with comment lines. I suggest that there is a problem with GetVHDLInsert(). I can not find function with name GetVHDLInsert in my vim source. Maybe you mean GetVHDLindent?. The problem may have something to do with how tabstop and softtabstop are set. Detailed Description: - With tabstop=4, when either opening a new comment line, or continuing in text insert mode from one comment line to the next, the new comment line will autoindent as one expects, ie it will start in-line with the previous comment line, BUT, after typing some text, the line will suddenly re-indent itself, usually a couple of spaces from the beginning of the line. I can not reproduce this behavior. But I can see that indentation is incorrect when tabstop is not 1. Maybe we have different versions of an indent file? I have version 1.36 by Gerald Lai laigera+vim?gmail.com. I can see that there is an updated version - 1.40 on vim.org, but it does not differ in the indentation logic from 1.36. After changing from tabstop=4 to tabstop=8, and setting softabstop=4, a new comment line will autoindent itself a long way in to the right from the previous line. This is purely a guess, but it seems to be treating spaces as though they were tabs? I have attached bugreport.txt as created by bugreport.vim, and also one of my VHDL files. Except for the vim version this bugreport is useless as for me. You shall use bugreport.vim just after you've reproduced the bug. Otherwise it contains rather general information, while your bug is very specific. In any case, automatically generated bug report does not contain script versions, so you shall include them in order to ensure we are on the same page. And the file you have attached it is so huge. Can the bug be reproduced on a small file? One or two lines length. Anyway, I have fixed a bug in my version of a VHDL indent script. Maybe this is the same bug you are experiencing. Please, try it. You should put the attached file into a $HOMEPATH\vimfiles\indent folder. vhdl.vim Description: application/octetstream
