Thanks to a hint from Dan Sharp, menus do work now when Vim is compiled with
the free Borland C compiler 5.5.

There is one remaining problem that I could not solve yet: When running the
OLE version, it cannot register itself.  After successfully registering (using
a gvim compiled with MS-VC) it does run normally.  Does anyone know why
registering doesn't work?

Here is the new Makefile.bor file (uuencoded .zip file):

begin 644 borland.zip
M4$L#!!0````(`)=F@2A<VQYE-1```"@O```,`!4`36%K969I;&4N8F]R550)
M``/]U.4X2];E.%5X!`#H`^@#O3K]<^,VKC_+?P7S,5U[-W(^M]=5Z][ZJUO?
M.;;'=K;OWF0F(TNTHXLLJ9(<)V_ZQS\`)"52UN[V9CJWL[%)`@0!$``!TB>-
M$W;K/O%U$'*VCE/V.=BV8:P?;Q,82AW6B]/0C7S6?_>.O6]?,&R';LY3=GUE
MKX*<>1(59K&EFVYXGCEL$&>7WS.@]UL075^Q)GSY\3YCDR414-T/[UNLN0_R
MQW/\B'<Y^W0W:C5.B(,H3X/5+N<^6[VR'H_8(H@V/$7V[A+?1<#-^>6'#W]#
M^#R.6-=-XZAQ8GTO1FWF^CX@9;LDB=.<Q`.FD.?!=`%XDSCG#LL?@XP]NAE;
M<5@CYQD0/B,N]W'ZE)W1O%[_?9NQ?\6[E&U!6'?#V=9]9<]N^@K\6+^JZ2G'
MI6#1R73)\IA(,)0-*+";]OLKH'+KOJXX0\VY$<QBZ^"%^W\'*I<7BG&0`SX)
MP%:[3<;VYT@`]'\%>#\@V@\%VDXJ@Y:)^)[E8A?.)($LWG*6Y;OU&K>(_EV?
M7UU<7,#<7NIN'>#()X8,;M^WW[-URCEN\)9V/8AXL=MGP(=E>:"*");8):B*
MP%V%/&O3]HUR8#P(_8P!C^5VDUXG2WL4Y3P\8TD:^SL/MA5V`7AT@=%5$(%2
M61`Q#HR067ENQD%ORUB09+L,9]P&7AIG\3H'F\UV;H@6>@8P7AAT>W]]);A9
MXAYG8&"AKPF):Y*$RL;K)67//,T"$`,T0L8'2[@:[A,G&W(`]%/BYH\_WX,,
M]UM@@IVO2V96:$;3>4?@L/%H\L^.AA_`HD_7L+T-H!/RG+@C(KL<8/DK\V,:
M>W13(833:'?OEM/!<#:<#!KM?K?_ZU`;0+D_=^>C;F\\7"!S$:C7LI[=<,=9
MT^=K=Q?FPM>`+<M"5M!DTSC.6;PN'1_V(LO=,&1-S[E?>>]A#G%O64@149$M
M9!^"0O.T"=1:)%*.8X@-3FU9%Q@.+AV6H6PQNV3!FKW&.[9W(R$L8!6J;E[B
MO-EP/K8L8!7W`^8<)SP-V_R%'V,/;)S-8*!P\&8$G`ML'Z=/Q\.:9>&#U`I0
MMGD.MJQY0<@+RX*P(*/6:$)1"[\0.!CV[CY9EJ1Q;#\?%]P'V2-8`R%LT"R%
MB599Z<.N?+KKS@<:C4_'I@IB,MX"\Y#&[,ZR@/_'--YM'MGW*%/(O1P!.%L:
M+,6KYC7.N%L,!^-QK0IP*53Z?!?EP1:W;Y6BWP&^5/[GT:T^V4LY1!D&"@.G
M\L-0A$@(*RO6W+1@&/=%ZK(['GV:`*]G[`IGWSBL&P:;:,M+,9LWQ"<=#XB&
M'5(_SO^ENUCVNU_A/.6;`.)T:J\@-/ALO8N\',T&XDD>>W$H19C.EJ/;T?\.
MK<5L.!P@K<6LVQ]"S']-R'#C!(0/_L^ER4W"(H\X(9]P"E]`3?4*1R#TQA%L
M7O-8F/MQIW-\W&I`DW68\)+&$8_\8"VIH;\X;'+@+\`*-I`U%0`479RB").[
M=9CTK=YH<K\<`[:Y!OB/`RI"36JN=,8N:,B+HRP&ZY##Q3)XX,I5<%:'79I4
MT0<=!@J&>`?[!]JF`Y-"I&Z^B>Z)$+W!(N"(>"-,\`T$+YY%;W+82;XU#T:<
M>`9PA#Y%\9[M'_%,I84[RN$;V!N/>AU0+H[=@[U*!L&/'2EC%*=;.`C0J\^D
M)@!J>VZ")Y/T]C@*7\71+M87&0=&`Y1=TEPXPAJ5D=+Q==V^++4J0H0._O#^
M_,,/YY.E.%NK>IXNE)JG"UB)IIN:IACBL#NEZB)209H`*O!V.4F!2_H<L@(,
M-XT3F@4$[6=)I@@@%5+*X\L`0SD!:XK$`DV0\KH6G!4E#A+^I"C/[H0KOF(>
M)+(,=#F/9QG%'%P&'%B)#/A*9@Q1'79M"MR7S&'>)QE,4B[#F,\>.:0E:<::
M:Q=]_0Q":XY(8'QQGJ$?^4'V=-1JP+$W&,Y1J_:O\+^#P<C+MM#TY$K""I69
M@!/G@0>._"J\T"^.':"9[B(;(Z(R(`R(J0B2A6""G))-]`X]1P10Y9(N4=(6
M`C!K8IHX'_:GM[=P9$/P06^-,>V!<X4W3@0)S3`ILCK,+<(I^I_/LR"%3+9Y
M>:;B;7:^8O41MMP>HJ6$H$&RTDY'QF&"P]IHIB%PH_HW2DQ#6A6SG3)*JR&&
MNL:S$6+0,S!-P5:3^J@BMF)0S5<\%O0.5*T"O<-$I`<&9&@7_I(E')-ZBO[E
M0C+B&QM0^JLD67BM[,/B-,MD8"$3-IE60:0&!_\\G+<*)S;3:\\3V22L%L$<
M)K`;X@L->2":G8N7BQO,U`</%#'P<[*4HQH+;.%&F"-ZC]R#P(8R(SON*G[F
MI`J(_N#7==M,0TWAK>\N6C_?P!!/4Z"`3GN[RW(L4B"QSX`DA"(`\-\QWP;)
M;LISNV1&$13VA22O"I+"AKY.]*J6*)J@!4ELG"N0R?=/U[5\;RAM28T%KH5C
MZ!'89)X4=-01Z1_[[KMB1*E,KH/*)CU#2%?U#W,W;A`YC&8P."F18WDN<O](
MW[.IEGU`S>R!(J"NA%)2.+2O.4EW.9I.L*S&4U(@'K7DAJ+]T"F`-HJV,_69
M/9%.J^11UMSID!.T"MQ+9J]MP(<_7\Y1H"L!\@5TZKGP42A,T"U<M-.Y5#1I
MM1:SDU1#)BLOCI4*YG-@5S:BSDYW1`..:]44T5'U1!@N]"O+/=37H_M,Y8/0
MFP/95(\5R10F$J-)?WPW&):#0>2%.Y__>-J4>4?KWHM3_F/[1\HP&X/A+Z/)
M<*$<%1(!>S#KEUY?;@S.U]!/F[(-4@]^[7X>/B#"PVBR',YG!A\X7JQ[VI2@
MEFX_@RE=,TB[6?$PWJ-)B+/6%IY11&W;51Y9M1K)4<?@38`.W&(\%#O]-8D`
MZ6`B)EE?FPB;]P`X#TJ9V.^/1[/>%*W%8'?9G7\:HO5@.N=3<BC,U@#(<=V8
MA+D(-H;_,US^:S;LV+\-OL22LBZB7>(7LBU@O>7=;-K[!^;\%WC7$*_^3:GZ
M%>G;;<R'BU]&E%@B1RG/2J>LD:<BSHE,:?=8:;WNW5='&CP&%4IB5937LOV*
M:^BT:S2BNY>R`GMPN\#KL4+B;5@5-=0%/5!0OXK^<J"9!`+)@MDQLV>*HT)5
M:D#Q*'.MKQG/PWPYUER_$A-[_QB,YE0\@;CWP(B_VIC!L3#.JI57YX8<Y9!!
MTH1M!$3&L!H$`R[X/#FA0K.[&$)DO)V!^//SY70Z7K#YW1C$)'C=7O7F?5!4
MO\\8,XI"2"L:XU_&W4\+6-9>^IS9'K,A$1YC.=EKD=I`*=B@W6A)=+0JI$@=
MW**]C7_N+L.OQ$V9/2IC$"36`)[90$6FWBTI,S'&5JGWG]6QY3E<*Q.`2ZG0
M<("=9?(?"H=3_&]/^=,JF(F3\06^YDOX>,(C,M!4(D[-=7&R@6R72->#!KE!
MC-*BK/U^B[V#'2:#:=VO/*_MK3=X#QALDS#P('5,=Y`K.8VVAY[D-"PQ"3\O
MQ==5Z_0C.WW;]AJ`E"3?1$N21NTAB]O(3B!+A:K!:4#8V$(V`US>(S'%89P]
M0+B#>$)^71->81Y0^/)4/Q0Q1%C-M["+A4SW@6DP2AHL*;1,`BNH<'F*L\UQ
M.#-3J&0/`7ZP2=WD\1#`_:`&G3^[8<WHRX.W];-:@!\#J!8"U708'4+P\CB(
M#\<!':4X!*`:ZD;3IYI1OJ7+Z3H`7O'4`:)=W6B6N9LZ]"#S+NN'KVJ&H79:
MO>8U=,35SN%XG-2H610\A^._[P+O:1V\'$)2ON$OR>%XYJ6<UU#*N)MZ-5:2
MO4:Y6T,_=S<U@SS='H[N@IJQR*^Q`'GF'P+V="-%/G-PIIE>`\V*QP3KAS@T
M_,U(96NGXY.208&N[2HD:F($A($*L4IF.A[K&0S$#;QYEE'C`"AAVA&LH_P[
MYJMX566H./J_I99-W;;`X(/*^RJ$*:C*]X-OT<8HA_%6A<3#L/PG*&PS/\YT
M3B"S"-T5VS^Z.=M#69E",1S34UO,_-AIW"[PVE`\].*P*%A/FT)CV`*;D9TS
MNK9P#K0F:)PVX;LE*C,SOU1&9^!I]4%-CF>@FC5=C1$9V$7&_N4*U<!7(&U&
M:7L&IE$-2;2RF#50RV&);D"]9->1A9DQ3N\CG:)":QS)@"KAM6>UV!N1#<M]
M,O-:75$Z<N$6135Y2$HWA3)A+1[XT2(=Y@=IICF^3%PT&@WKH\]#5ANR&@V<
M[E#PL#]N?6&`1E=,:C3<,'30Q_$OW47TTB3?8JC]\N(S#T)L)G/JO^:?I,7P
M9P+@0<A#CT/-Q>G2U<USODW*2_HWP,0;O&9Z0YR\.9//@Q"3)!UU#8&9!-9M
M0<J@)$RXEP?/XJE7/5HS;&3&,XDB4KS*MAF^L0>9N.!(?7$]/L(?%<"('^.%
M(Q:(P,717ZH5D!,RRX^>CVK'('3;_2<FQ&M#!('1;C<:I`XY0VS2M^=HFPM6
M%F?8A]36TNJ"%=8%#,I-9G/U0%UB-NB7";"J309X_JK9X-OV6VW\+=7E>A^/
M$:T/-O>6:F<=Q\NV1G_K0CZM>Y93+BB"MCCKT+YE2<0^?O?='RA24:5`%="P
MO`M?G`38,69:IS^=G;X]##^6MX$98;!Z]Z7P:\&)?K472.P`2SNI+"@XXC0O
MR&D'OU6Y"Z-GN+I5]6!N>;!J@%@R,M&`[-,D"V\F8)$"'NK0/VHSAR(PF4HN
ME2\T+LJ!TZ:\6E#!\0NSU;EJX!,37]JQEMBA\K8#!VK8M4INE)1:OB/54.QM
M=4O^LNW^[^]M-5O`=:K*E5/Y=B>X90<&4%?,.8S)CJ<C:%6=8ZF.@:&5=XZE
M.@:&JO-@"6J:0%GN(1";)K"L^AQ+=3RF6H\5W*(01&*J^V7THCH4Z*)KK%\6
MBH`B.P:"5C$ZENH8&*IT!`+4K`!%!4E`:)K`LI!T+-6I8JB*DC"H4\$0I26"
MH56!%04F@D7'Q%"5)O)'[0/PE0:^JH"URA,Q5-=`*HM00)$=`T%6HP#%5@6D
M:E*"4L=`T(M30"FZ!E)9IP**[!@(9<$*"+)C(A25*R*(CHE0E+"((#H&@JQE
M`8HM$R0K6H1ATP"*"@I`T#`!LKI%$#8-H)8Q.I;JF)K5RB?4K>I6D8H*22")
MKH%4ULV`(CNF!RD9-E49M%*0H-0Y8+.X^7)8V36PRO+;8;)-=W5?N!-3=+#K
M5>[[[-^&Y9V?CE82HP0)HC2^4?*7(,NU-"G:A6S[!#FZ3,S_)*;*V6OO`T@F
MZE29+1BU$T]#@E10M<NY+QG]@`MS+GERM9AV@@U?\KL\"+/[EVRW2A)\B(SS
M&&=DS)83L7P6MQ:'TQ2*MMS/[/0C73ABLNB(UQQ/O;FT\6>3<9BU5]L$S-Y-
MX_6:VH@6>#%^/]"+<=%S0Y[F12^(UG'1^7W',P+)6Y7>O-\RGCN"RB,ELS$/
M3O%6-_6P1BN+)"K35%N->[6'N7[CWN^KS!I?AXU;;_764A!C>.AO<R,/^'.T
M2G9D=:F?]**2=(Q?SX)"O#AY93()$S?UQ+I2#K;E0Y0<Q\M]NBB9+>F[2*-$
M#^MPJZBZ_Z!=1@4Z^"NG+,\Z-RS;=VZ<QO\#4$L!`A8#%`````@`EV:!*%S;
M'F4U$```*"\```P`#0```````0```*2!`````$UA:V5F:6QE+F)O<E54!0`#
>_=3E.%5X``!02P4&``````$``0!'````=!``````
`
end

--
BRIDGEKEEPER: What is your favorite colour?
GAWAIN:       Blue ...  No yelloooooww!
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

Patch 5.6.048
Problem:    CTRL-R in Command-line mode is documented to insert text as typed,
	     but inserts text literally.
Solution:   Make CTRL-R insert text as typed, use CTRL-R CTRL-R to insert
	     literally.  This is consistent with Insert mode.  But characters
	     that end Command-line mode are inserted literally.
Files:     runtime/doc/index.txt, runtime/doc/cmdline.txt, src/ex_getln.c,
	     src/ops.c, src/proto/ops.pro


*** ../vim-5.6.47/runtime/doc/index.txt Sun Jan 16 14:12:56 2000
--- runtime/doc/index.txt Sat Apr  1 20:57:07 2000
***************
*** 1,4 ****
! *index.txt*     For Vim version 5.6.  Last change: 2000 Jan 01


  		   VIM REFERENCE MANUAL    by Bram Moolenaar
--- 1,4 ----
! *index.txt*     For Vim version 5.6.  Last change: 2000 Apr 01


  		   VIM REFERENCE MANUAL    by Bram Moolenaar
***************
*** 831,838 ****
   |c_CTRL-P| CTRL-P  after using 'wildchar' with multiple matches:
  				 go to previous match, otherwise: same as <Up>
   |c_CTRL-Q| CTRL-Q  same as CTRL-V (used for terminal control flow)
! |c_CTRL-R| CTRL-R {0-9a-z"%#*:=}
! 			 insert the contents of a register
  		 CTRL-S  (used for terminal control flow)
   |c_CTRL-U| CTRL-U  remove all characters
   |c_CTRL-V| CTRL-V  insert next non-digit literally, insert three
--- 831,842 ----
   |c_CTRL-P| CTRL-P  after using 'wildchar' with multiple matches:
  				 go to previous match, otherwise: same as <Up>
   |c_CTRL-Q| CTRL-Q  same as CTRL-V (used for terminal control flow)
! |c_CTRL-R| CTRL-R {0-9a-z"%#*:= CTRL-F CTRL-P CTRL-W CTRL-A}
! 			 insert the contents of a register or object
! 			 under the cursor as if typed
! |c_CTRL-R_CTRL-R| CTRL-R CTRL-R {0-9a-z"%#*:= CTRL-F CTRL-P CTRL-W CTRL-A}
! 			 insert the contents of a register or object
! 			 under the cursor literally
  		 CTRL-S  (used for terminal control flow)
   |c_CTRL-U| CTRL-U  remove all characters
   |c_CTRL-V| CTRL-V  insert next non-digit literally, insert three
*** ../vim-5.6.47/runtime/doc/cmdline.txt Sun Jan 16 14:12:53 2000
--- runtime/doc/cmdline.txt Sat Apr  1 21:11:03 2000
***************
*** 1,4 ****
! *cmdline.txt*   For Vim version 5.6.  Last change: 2000 Jan 09


  		   VIM REFERENCE MANUAL    by Bram Moolenaar
--- 1,4 ----
! *cmdline.txt*   For Vim version 5.6.  Last change: 2000 Apr 01


  		   VIM REFERENCE MANUAL    by Bram Moolenaar
***************
*** 119,126 ****
  		 Insert the contents of a numbered or named register.  Between
  		 typing CTRL-R and the second character '"' will be displayed
  		 to indicate that you are expected to enter the name of a
! 	 register.  The text is inserted as if you typed it, but
! 	 mappings and abbreviations are not used.  Special registers:
  			 '"' the unnamed register, containing the text of
  				 the last delete or yank
  			 '%' the current file name
--- 119,132 ----
  		 Insert the contents of a numbered or named register.  Between
  		 typing CTRL-R and the second character '"' will be displayed
  		 to indicate that you are expected to enter the name of a
! 	 register.
! 	 The text is inserted as if you typed it, but mappings and
! 	 abbreviations are not used.  Characters that end the command
! 	 line are inserted literally (<Esc>, <CR>, <NL>, <C-C>).  A
! 	 <BS> or CTRL-W could still end the command line though, and
! 	 remaining characters will then be interpreted in another mode,
! 	 which might not be what you intended.
! 	 Special registers:
  			 '"' the unnamed register, containing the text of
  				 the last delete or yank
  			 '%' the current file name
***************
*** 147,152 ****
--- 153,166 ----
  		 CTRL-F and CTRL-P: {only when +file_in_path feature is
  		 included}

+ 				 *c_CTRL-R_CTRL-R* *c_<C-R>_<C-R>*
+ CTRL-R CTRL-R {0-9a-z"%#:-=. CTRL-F CTRL-P CTRL-W CTRL-A}
+ 	 Insert register or object under the cursor.  Works like
+ 	 |c_CTRL-R| but inserts the text literally.  For example, if
+ 	 register a contains "xy^Hz" (where ^H is a backspace),
+ 	 "CTRL-R a" will insert "xz" while "CTRL-R CTRL-R a" will
+ 	 insert "xy^Hz".
+
   CTRL-J 				 *c_CTRL-J* *c_<NL>* *c_<CR>*
   <CR> or <NL> start entered command
  							 *c_<Esc>*
*** ../vim-5.6.47/src/ex_getln.c Sat Mar 25 17:13:09 2000
--- src/ex_getln.c Sat Apr  1 20:30:58 2000
***************
*** 726,732 ****
   #endif
  		 putcmdline('"');
  		 ++no_mapping;
! 	 c = safe_vgetc();
  		 --no_mapping;
   #ifdef WANT_EVAL
  		 /*
--- 726,734 ----
   #endif
  		 putcmdline('"');
  		 ++no_mapping;
! 	 i = c = safe_vgetc(); /* CTRL-R <char> */
! 	 if (c == Ctrl('R'))
! 		    c = safe_vgetc(); /* CTRL-R CTRL-R <char> */
  		 --no_mapping;
   #ifdef WANT_EVAL
  		 /*
***************
*** 754,760 ****
  		 }
   #endif
  		 if (c != ESC)     /* use ESC to cancel inserting register */
! 		    cmdline_paste(c);
  		 redrawcmd();
  		 goto cmdline_changed;

--- 756,762 ----
  		 }
   #endif
  		 if (c != ESC)     /* use ESC to cancel inserting register */
! 		    cmdline_paste(c, i == Ctrl('R'));
  		 redrawcmd();
  		 goto cmdline_changed;

***************
*** 826,835 ****
  			 goto cmdline_not_changed;   /* Ignore mouse */
   # ifdef USE_GUI
  		 if (gui.in_use)
! 		    cmdline_paste('*');
  		 else
   # endif
! 		    cmdline_paste(0);
  		 redrawcmd();
  		 goto cmdline_changed;

--- 828,837 ----
  			 goto cmdline_not_changed;   /* Ignore mouse */
   # ifdef USE_GUI
  		 if (gui.in_use)
! 		    cmdline_paste('*', TRUE);
  		 else
   # endif
! 		    cmdline_paste(0, TRUE);
  		 redrawcmd();
  		 goto cmdline_changed;

*** ../vim-5.6.47/src/ops.c Mon Dec 13 16:07:36 1999
--- src/ops.c Sat Apr  1 21:08:46 2000
***************
*** 86,91 ****
--- 86,92 ----
   static int put_in_typebuf __ARGS((char_u *s, int colon));
   static void stuffescaped __ARGS((char_u *arg));
   static int get_spec_reg __ARGS((int regname, char_u **argp, int *allocated,
int errmsg));
+ static void cmdline_paste_str __ARGS((char_u *s, int literally));
   static void free_yank __ARGS((long));
   static void free_yank_all __ARGS((void));
   static void block_prep __ARGS((OPARG *oap, struct block_def *, linenr_t,
int));
***************
*** 1171,1178 ****
    * return FAIL for failure, OK otherwise
    */
       int
! cmdline_paste(regname)
       int regname;
   {
       long i;
       char_u *arg;
--- 1172,1180 ----
    * return FAIL for failure, OK otherwise
    */
       int
! cmdline_paste(regname, literally)
       int regname;
+     int literally; /* Insert text literally instead of "as typed" */
   {
       long i;
       char_u *arg;
***************
*** 1198,1207 ****
       {
  	 if (arg == NULL)
  	     return FAIL;
!  i = put_on_cmdline(arg, -1, TRUE);
  	 if (allocated)
  	     vim_free(arg);
!  return (int)i;
       }

       get_yank_register(regname, FALSE);
--- 1200,1209 ----
       {
  	 if (arg == NULL)
  	     return FAIL;
!  cmdline_paste_str(arg, literally);
  	 if (allocated)
  	     vim_free(arg);
!  return (int)OK;
       }

       get_yank_register(regname, FALSE);
***************
*** 1210,1222 ****

       for (i = 0; i < y_current->y_size; ++i)
       {
!  put_on_cmdline(y_current->y_array[i], -1, FALSE);

  	 /* insert ^M between lines and after last line if type is MLINE */
  	 if (y_current->y_type == MLINE || i < y_current->y_size - 1)
! 	    put_on_cmdline((char_u *)"\r", 1, FALSE);
       }
       return OK;
   }

   /*
--- 1212,1252 ----

       for (i = 0; i < y_current->y_size; ++i)
       {
!  cmdline_paste_str(y_current->y_array[i], literally);

  	 /* insert ^M between lines and after last line if type is MLINE */
  	 if (y_current->y_type == MLINE || i < y_current->y_size - 1)
! 	    cmdline_paste_str((char_u *)"\r", literally);
       }
       return OK;
+ }
+
+ /*
+  * Put a string on the command line.
+  * When "literally" is TRUE, insert literally.
+  * When "literally" is FALSE, insert as typed, but don't leave the command
+  * line.
+  */
+     static void
+ cmdline_paste_str(s, literally)
+     char_u *s;
+     int  literally;
+ {
+     if (literally)
+  put_on_cmdline(s, -1, TRUE);
+     else
+  while (*s)
+  {
+ 	    if (*s == Ctrl('V') && s[1])
+ 	 stuffcharReadbuff(*s++);
+ 	    else if (*s == ESC || *s == Ctrl('C') || *s == CR || *s == NL
+ #ifdef UNIX
+ 		    || *s == intr_char
+ #endif
+ 		    || (*s == Ctrl('\\') && s[1] == Ctrl('N')))
+ 	 stuffcharReadbuff(Ctrl('V'));
+ 	    stuffcharReadbuff(*s++);
+  }
   }

   /*
*** ../vim-5.6.47/src/proto/ops.pro Sun Jan 16 14:22:46 2000
--- src/proto/ops.pro Sat Apr  1 20:59:39 2000
***************
*** 13,19 ****
   int do_record __ARGS((int c));
   int do_execreg __ARGS((int regname, int colon, int addcr));
   int insert_reg __ARGS((int regname, int literally));
! int cmdline_paste __ARGS((int regname));
   int op_delete __ARGS((OPARG *oap));
   int op_replace __ARGS((OPARG *oap, int c));
   void op_tilde __ARGS((OPARG *oap));
--- 13,19 ----
   int do_record __ARGS((int c));
   int do_execreg __ARGS((int regname, int colon, int addcr));
   int insert_reg __ARGS((int regname, int literally));
! int cmdline_paste __ARGS((int regname, int literally));
   int op_delete __ARGS((OPARG *oap));
   int op_replace __ARGS((OPARG *oap, int c));
   void op_tilde __ARGS((OPARG *oap));
*** ../vim-5.6.47/src/version.c Fri Mar 31 19:36:49 2000
--- src/version.c Sat Apr  1 21:12:33 2000
***************
*** 420,421 ****
--- 420,423 ----
   {   /* Add new patch number below this line */
+ /**/
+     48,
   /**/

--
It is illegal for a driver to be blindfolded while operating a vehicle.
		 [real standing law in Alabama, United States of America]

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

Maurice S. Barnum wrote:

> on a vaguely related subject, i think that using the -pr switch ("use
> register calling convention by default") was a mistake that has resulted in
> the Vim source being littered with "#ifdef __BORLANDC__".  the performance
> advantage of the register calling convention will only come into play
> with rather small functions:  otherwise, the parameter will likely get
> pushed onto the stack to free up the register in which it's sitting.
>
> would you be interested in a tested patch that removes this clutter?

Having system or compiler specific #ifdefs in many files is certainly a
disadvantage.  And when making changes these __BORLANDC__ things may need to
be updated too.  If there is no noticable performance difference, I would
rather get rid of them.

> : There is one remaining problem that I could not solve yet: When running the
> : OLE version, it cannot register itself.  After successfully registering
> : (using a gvim compiled with MS-VC) it does run normally.  Does anyone know
> : why registering doesn't work?
>
> I don't, but i'll take a look at it.

Please do, it's probably simple to solve if you know how to do it...

--
There is no right or wrong, there is only your personal opinion.
                  (Bram Moolenaar)

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

Bram Moolenaar <Bram@...> writes:

: Thanks to a hint from Dan Sharp, menus do work now when Vim is compiled with
: the free Borland C compiler 5.5.
:

on a vaguely related subject, i think that using the -pr switch ("use register
calling convention by default") was a mistake that has resulted in the
Vim source being littered with "#ifdef __BORLANDC__".  the performance
advantage of the register calling convention will only come into play
with rather small functions:  otherwise, the parameter will likely get
pushed onto the stack to free up the register in which it's sitting.

would you be interested in a tested patch that removes this clutter?


: There is one remaining problem that I could not solve yet: When running the
: OLE version, it cannot register itself.  After successfully registering (using
: a gvim compiled with MS-VC) it does run normally.  Does anyone know why
: registering doesn't work?

I don't, but i'll take a look at it.

  --xmsb

Bram Moolenaar wrote:
>
> Maurice S. Barnum wrote:
>
> > on a vaguely related subject, i think that using the -pr switch ("use
> > register calling convention by default") was a mistake that has resulted in
> > the Vim source being littered with "#ifdef __BORLANDC__".  the performance
> > advantage of the register calling convention will only come into play
> > with rather small functions:  otherwise, the parameter will likely get
> > pushed onto the stack to free up the register in which it's sitting.
> >
> > would you be interested in a tested patch that removes this clutter?
>
> Having system or compiler specific #ifdefs in many files is certainly a
> disadvantage.  And when making changes these __BORLANDC__ things may need to
> be updated too.  If there is no noticable performance difference, I would
> rather get rid of them.

The shouldn't be any. Modern ix86 processors have register renaming,
TLB's
fast 1 level caches... even more some have dedicated stack caches...

>
> > : There is one remaining problem that I could not solve yet: When running
the
> > : OLE version, it cannot register itself.  After successfully registering
> > : (using a gvim compiled with MS-VC) it does run normally.  Does anyone know
> > : why registering doesn't work?
> >
> > I don't, but i'll take a look at it.
>
> Please do, it's probably simple to solve if you know how to do it...
>
> --
> There is no right or wrong, there is only your personal opinion.
>                  (Bram Moolenaar)
>
> /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
> \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

--
	 Marcin Dalecki

Maurice S. Barnum <pixi@...> writes:
>Bram Moolenaar <Bram@...> writes:
>
>: Thanks to a hint from Dan Sharp, menus do work now when Vim is compiled with
>: the free Borland C compiler 5.5.
>:
>
>on a vaguely related subject, i think that using the -pr switch ("use register
>calling convention by default") was a mistake that has resulted in the

Ahem.  If I may interject, I am the one who made the Borland compiles use
register calling convention.

Before you turn off the feature, benchmark the behaviour with and without it.
I saw a 15-30% speed improvement with the feature on, as well as a size
reduction in the executable.  The benefit will be different depending on the
processor class etc, but do be sure to test on 486, Pentium and newer
processors -- and realize that *many* people use older CPUs.

In my judgement, the benefit of 'fastcall' was worth cluttering the code with
a few #ifdefs.  YMMV.

>the performance
>advantage of the register calling convention will only come into play
>with rather small functions:  otherwise, the parameter will likely get
>pushed onto the stack to free up the register in which it's sitting.

Have you *benchmarked* this to verify what you are saying?  My experience is
different than what you indicate, but admittedly the source is fairly
different than the version I put 'fastcall' in.

>
>would you be interested in a tested patch that removes this clutter?

No, thanks -- I use the much better 'gcc-2.95.2' free compiler now :-)

Ron

"Ron Aaron" <ron@...> writes:


: Before you turn off the feature, benchmark the behaviour with and without it.
: I saw a 15-30% speed improvement with the feature on, as well as a size
: reduction in the executable.  The benefit will be different depending on the
: processor class etc, but do be sure to test on 486, Pentium and newer
: processors -- and realize that *many* people use older CPUs.
:
: >the performance
: >advantage of the register calling convention will only come into play
: >with rather small functions:  otherwise, the parameter will likely get
: >pushed onto the stack to free up the register in which it's sitting.
:
: Have you *benchmarked* this to verify what you are saying?  My experience is
: different than what you indicate, but admittedly the source is fairly
: different than the version I put 'fastcall' in.
:

well, numbers beats conjecture, that's for sure.  i don't have a 486
available, but i'll test on some slower machines and ask for help when
i have the patch ready.  out of curiosity, what did you use to make
the measurements, and was this for win32 or dos?

  --xmsb

Patch 5.6.050
Problem:    Replacing is wrong when replacing a single-byte char with
	     double-byte char or the other way around.
Solution:   Shift the text after the character when it is replaced.
	     (Yasuhiro Matsumoto)
Files:     src/normal.c, src/misc1.c


*** ../vim-5.6.49/src/normal.c Thu Mar 23 17:46:04 2000
--- src/normal.c Sun Apr  2 12:30:31 2000
***************
*** 4522,4531 ****
   #ifdef MULTI_BYTE
  	     if (is_dbcs)
  	     {
  		 if (trailbyte != NUL)
! 		    ptr[curwin->w_cursor.col++] = trailbyte;
  		 else if (IsLeadByte(prechar))
! 		    (void)del_chars((long)1, TRUE);
  	     }
   #endif
  	 }
--- 4522,4544 ----
   #ifdef MULTI_BYTE
  	     if (is_dbcs)
  	     {
+ 	 /* Handle three situations:
+ 		 * 1. replace double-byte with double-byte: set trailbyte.
+ 		 * 2. replace single-byte with double-byte: insert trailbyte.
+ 		 * 3. replace double-byte with single-bute: delete char.
+ 		 */
  		 if (trailbyte != NUL)
! 	 {
! 		    if (IsLeadByte(prechar))
! 		 ptr[curwin->w_cursor.col] = trailbyte;
! 		    else
! 		 (void)ins_char(trailbyte);
! 	 }
  		 else if (IsLeadByte(prechar))
! 	 {
! 		    (void)del_char(TRUE);
! 		    ++curwin->w_cursor.col;
! 	 }
  	     }
   #endif
  	 }
*** ../vim-5.6.49/src/misc1.c Fri Mar 31 14:23:12 2000
--- src/misc1.c Sun Apr  2 12:55:38 2000
***************
*** 1354,1359 ****
--- 1354,1363 ----
  	 extra = 1;
       else
  	 extra = 0;
+ #ifdef MULTI_BYTE
+     if (is_dbcs && State == REPLACE && IsLeadByte(c))
+  extra = 1;
+ #endif

       /*
        * A character has to be put on the replace stack if there is a
***************
*** 1410,1416 ****
  	 curwin->w_p_list = old_list;
       }

!     newp = alloc_check((unsigned)(oldlen + extra));
       if (newp == NULL)
  	 return;
       if (col > 0)
--- 1414,1431 ----
  	 curwin->w_p_list = old_list;
       }

! #ifdef MULTI_BYTE
!     if (State == REPLACE && is_dbcs)
!     {
!  /* For multi-byte add one byte when new char is multi-byte, subtract
! 	 * one byte when old char was multi-byte. */
!  newp = alloc_check((unsigned)(oldlen + extra
! 		    + (IsLeadByte(c) ? 1 : 0)
! 		    - (IsLeadByte(oldp[col]) ? 1 : 0)));
!     }
!     else
! #endif
!  newp = alloc_check((unsigned)(oldlen + extra));
       if (newp == NULL)
  	 return;
       if (col > 0)
***************
*** 1422,1438 ****
  	 mch_memmove(p + 1, oldp + i, (size_t)(oldlen - i));
       }
       else
!  mch_memmove(p + extra, oldp + col, (size_t)(oldlen - col));
!
   #ifdef MULTI_BYTE
!     /*
!      * We define that "[]" is a multi-byte character.  For example, if
!      * replace(R) is done over "a[]" with "[]".  Finally, "[]]" is
!      * constructed, but the following line replaces "[]]" with "[] ".
!      */
!     if (is_dbcs && State == REPLACE && IsLeadByte(*p) && p[1] != NUL)
!  p[1] = ' ';
   #endif
       *p = c;
       ml_replace(lnum, newp, FALSE);

--- 1437,1452 ----
  	 mch_memmove(p + 1, oldp + i, (size_t)(oldlen - i));
       }
       else
!     {
   #ifdef MULTI_BYTE
!  /* if oldp have multi-byte, don't move old trail byte */
!  if (is_dbcs && State == REPLACE && IsLeadByte(oldp[col]))
! 	    mch_memmove(p + extra, oldp + col + 1, (size_t)(oldlen - col - 1));
!  else
   #endif
+ 	    mch_memmove(p + extra, oldp + col, (size_t)(oldlen - col));
+     }
+
       *p = c;
       ml_replace(lnum, newp, FALSE);

*** ../vim-5.6.49/src/version.c Sun Apr  2 12:06:32 2000
--- src/version.c Sun Apr  2 13:01:09 2000
***************
*** 420,421 ****
--- 420,423 ----
   {   /* Add new patch number below this line */
+ /**/
+     50,
   /**/

--
Florida:
A special law prohibits unmarried women from parachuting on Sunday or she
shall risk arrest, fine, and/or jailing.
		 [real standing law in Florida, United States of America]

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

Patch 5.6.049
Problem:    Documentation for [!] after ":ijump" is wrong way around. (Benji
	     Fisher)
Solution:   Fix the documentation.  Also improve the code to check for a match
	     after a /* */ comment.
Files:     runtime/doc/tagsearch.txt, src/search.c


*** ../vim-5.6.48/runtime/doc/tagsearch.txt Sun Jan 16 14:13:00 2000
--- runtime/doc/tagsearch.txt Sun Apr  2 11:54:39 2000
***************
*** 1,4 ****
! *tagsearch.txt* For Vim version 5.6.  Last change: 1999 Aug 09


  		   VIM REFERENCE MANUAL    by Bram Moolenaar
--- 1,4 ----
! *tagsearch.txt* For Vim version 5.6.  Last change: 2000 Apr 02


  		   VIM REFERENCE MANUAL    by Bram Moolenaar
***************
*** 744,750 ****

  								 *:search-args*
   Common arguments for the commands above:
! [!]   When included, lines that are recognized as comments are skipped.
   [/]   A pattern can be surrounded by '/'.  Without '/' only whole words are
         matched, using the pattern "\<pattern\>".  Only after the second '/' a
         next command can be appended with '|'.  Examples:
--- 744,760 ----

  								 *:search-args*
   Common arguments for the commands above:
! [!]   When included, find matches in lines that are recognized as comments.
!       When excluded, a match is ignored when the line is recognized as a
!       comment (according to 'comments'), or the match is in a C comment (after
!       "//" or inside /* */).  Note that a match may be missed if a line is
!       recognized as a comment, but the comment ends halfway the line.
!       And  if the line is a comment, but it is not recognized (according to
!       'comments') a match may be found in it anyway.  Example:
! >  /* comment
! > 	   foobar */
!       A match for "foobar" is found, because this line is not recognized as a
!       comment (even though syntax highlighting does recognize it).
   [/]   A pattern can be surrounded by '/'.  Without '/' only whole words are
         matched, using the pattern "\<pattern\>".  Only after the second '/' a
         next command can be appended with '|'.  Examples:
*** ../vim-5.6.48/src/search.c Mon Mar 27 13:36:17 2000
--- src/search.c Sun Apr  2 11:47:17 2000
***************
*** 3442,3456 ****
  			  * Also check for a "/ *" or "/ /" before the match.
  			  * Skips lines like "int backwards;  / * normal index
  			  * * /" when looking for "normal".
  			  */
! 		 else
   #endif
  			     for (p = line; *p && p < startp; ++p)
! 			 if (p[0] == '/' && (p[1] == '*' || p[1] == '/'))
  				 {
  				     matched = FALSE;
! 				    break;
  				 }
   #ifdef COMMENTS
  			 fo_do_comments = FALSE;
   #endif
--- 3442,3472 ----
  			  * Also check for a "/ *" or "/ /" before the match.
  			  * Skips lines like "int backwards;  / * normal index
  			  * * /" when looking for "normal".
+ 			 * Note: Doesn't skip "/ *" in comments.
  			  */
! 		 p = skipwhite(line);
! 		 if (matched
! 			 || (p[0] == '/' && p[1] == '*') || p[0] == '*')
   #endif
  			     for (p = line; *p && p < startp; ++p)
! 			    {
! 			 if (matched
! 				 && p[0] == '/'
! 				 && (p[1] == '*' || p[1] == '/'))
  				 {
  				     matched = FALSE;
! 				    /* After "//" all text is comment */
! 				    if (p[1] == '/')
! 				 break;
! 				    ++p;
  				 }
+ 			 else if (!matched && p[0] == '*' && p[1] == '/')
+ 			 {
+ 				    /* Can find match after "* /". */
+ 				    matched = TRUE;
+ 				    ++p;
+ 			 }
+ 			    }
   #ifdef COMMENTS
  			 fo_do_comments = FALSE;
   #endif
*** ../vim-5.6.48/src/version.c Sun Apr  2 11:57:12 2000
--- src/version.c Sun Apr  2 11:55:39 2000
***************
*** 420,421 ****
--- 420,423 ----
   {   /* Add new patch number below this line */
+ /**/
+     49,
   /**/

--
You can be stopped by the police for biking over 65 miles per hour.
You are not allowed to walk across a street on your hands.
		 [real standing laws in Connecticut, United States of America]

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

As you all know (or should know), Vim is distributed under the charityware
concept: If you like using Vim, you are requested to help a childrens centre
in Uganda.  In March I visited the project to see how they are doing.  Below
is my report.  Hopefully this inspires you to (continue) support for the
project.  I will certainly do that myself!  You can also read it on the net,
with a couple of pictures:

	 http://www.vim.org/iccf/news.html

Also go there for more information on the project.  If you have any remaining
questions, ask me.


Clinic

There is a small clinic at the project, which has been improved over the last
couple of years. More and more villagers know how to find the place. I was
there on a market day, when over a hundred patients came for medical help. It
was really crowded with patients waiting for treatment. On other days there
are around thirty patients. Overall there are more than two hundred patients
each week. Thus the clinic is providing a very important service to the
community. I have spoken with a few locals, who said they are very happy with
the medical help.

The patients pay a small fee for treatment and medicine. This doesn't cover
the actual cost though. Only through donations can we keep the clinic running,
since the patients are not able to pay a higher fee. The Lisbloem school in
Lisse (The Netherlands) raised a large amount, which has been used to buy a
solar powered fridge. It stores the medicines that have to be kept in a cool
place. The picture shows assistant nurse Boaz with the new fridge. Boaz is one
of the orphans that grew up at the centre while I was working there in 94/95.
He has been able to get an education through the sponsorship program.  I was
happy to see he is now working for the centre.

There is one Ugandan nurse working full time, and a doctor visiting on market
days. Hopefully the quality of the service provided can be improved the coming
year. A small laboratory would be very useful, and more educated staff.


School

The vocational school had just been extended with a tailoring section. I
watched the pupils enjoying their first lessons. It is in a new building,
together with the carpentry section which started last year. The school now
goes from kindergarten, through primary and secondary to the vocational
school. All teachers are now Ugandans and have proper training. There is a
total of about four hundred children, who are enjoying the high quality of
this school.

Besides running the school in Kibaale, attention is given to teachers in
schools of nearby villages. Many of these have had no more training than
primary school themselves. Teacher training is now organised to improve their
knowledge and teaching abilities. The teacher resource centre provides them
with materials.

I really enjoyed watching the children going to school. And they stay until
late in the afternoon to play football and netball. Quite an improvement
compared to the situation in 1993, when I first visited the project. Only
three classes back then, and most teachers were not trained. Now the school is
an example for the area.


Sponsorship

Many children cannot afford to pay their school fees. Therefore sponsors pay
monthly to support them. I have visited eight of the sponsored children at
their homes. The picture shows Nabasagi Morine, one of our youngest children.
She is six years old and goes to the kindergarten class.

Generally, these families are only just able to manage their household. They
have the basic things like a house, some clothes and grow their own food.
Nothing more than that. One family was below the average level though. Their
house is leaking, there are no blankets for the children and no mattresses. I
have asked the manager to give them at least a couple of blankets. Hopefully
we find a way for them to be able to take care of themselves. That is better
than have them depend on our gifts.

There are still a lot of children who are not sponsored. Hopefully we will
find more sponsors this year. The office that takes care of the sponsored
children, called Kibaale Childrens Fund (KCF) is running very well. There are
two Ugandans, who visit the children, managed by a Canadian volunteer. They
make sure the children are able to attend school, visit them at home and take
them to hospital when needed. I accompanied three children to hospital,
together with an assistant nurse. The garden of the hospital looks great, but
the quality of the medical care is low. But there is no other place with a
qualified doctor and a laboratory. We might try to improve our own clinic to
work around this problem.


Conclusion

I can see quite a bit of improvement since my last visit in 1998. Roads have
been fixed, there is more traffic and business.  The Kibaale Childrens Centre
is running very well and mainly with Ugandan staff. The school is operating
very well, and the clinic provides health care to many patients. The coming
time will be focused on maintaining the project and further improving the
quality. I will certainly support that.

- Bram Moolenaar

--
Any sufficiently advanced technology is indistinguishable from magic.
					 Arthur C. Clarke

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

Patch 5.6.051
Problem:    ":tprev" and ":tnext" don't give an error message when trying to
             go before the first or beyond the last tag. (Robert Webb)
Solution:   Added error messages.  Also: Delay a second when a file-read
             message is going to overwrite an error message, otherwise it won't
             be seen.
Files:      src/fileio.c, src/tag.c


*** ../vim-5.6.50/src/fileio.c Fri Mar 31 14:23:11 2000
--- src/fileio.c Sun Apr  2 21:29:16 2000
***************
*** 95,100 ****
--- 95,102 ----
       msg_scroll_save = msg_scroll;
       if (shortmess(SHM_OVERALL))
  	 msg_scroll = FALSE;
+     if (!msg_scroll) /* wait a bit when overwriting an error msg */
+  check_for_delay(FALSE);
       msg_start();
       msg_scroll = msg_scroll_save;
       /* may truncate the message to avoid a hit-return prompt */
*** ../vim-5.6.50/src/tag.c Fri Mar 31 14:23:13 2000
--- src/tag.c Sun Apr  2 21:06:24 2000
***************
*** 146,151 ****
--- 146,152 ----
       char_u  **new_matches;
       int 	 attr;
       int 	 use_tagstack;
+     int 	 skip_msg = FALSE;

       /* remember the matches for the last used tag */
       static int  num_matches = 0;
***************
*** 314,320 ****
--- 315,325 ----
  		 if (cur_match >= MAXCOL)
  		     cur_match = MAXCOL - 1;
  		 else if (cur_match < 0)
+ 	 {
+ 		    EMSG("Cannot go before first matching tag");
+ 		    skip_msg = TRUE;
  		     cur_match = 0;
+ 	 }
  	     }
  	 }

***************
*** 629,635 ****
--- 634,650 ----
  	     }

  	     if (cur_match >= num_matches)
+ 	    {
+ 	 if (type == DT_NEXT || type == DT_FIRST)
+ 	 {
+ 		    if (num_matches == 1)
+ 		 EMSG("There is only one matching tag");
+ 		    else
+ 		 EMSG("Cannot go beyond last matching tag");
+ 		    skip_msg = TRUE;
+ 	 }
  		 cur_match = num_matches - 1;
+ 	    }
  	     if (use_tagstack)
  	     {
  		 tagstack[tagstackidx].cur_match = cur_match;
***************
*** 649,655 ****
   #ifdef USE_CSCOPE
  		 && type != DT_CSCOPE
   #endif
! 	 && (num_matches > 1 || ic))
  	     {
  		 /* Give an indication of the number of matching tags */
  		 sprintf((char *)msg_buf, "tag %d of %d%s",
--- 664,671 ----
   #ifdef USE_CSCOPE
  		 && type != DT_CSCOPE
   #endif
! 	 && (num_matches > 1 || ic)
! 	 && !skip_msg)
  	     {
  		 /* Give an indication of the number of matching tags */
  		 sprintf((char *)msg_buf, "tag %d of %d%s",
*** ../vim-5.6.50/src/version.c Sun Apr  2 13:04:17 2000
--- src/version.c Sun Apr  2 21:39:35 2000
***************
*** 420,421 ****
--- 420,423 ----
   {   /* Add new patch number below this line */
+ /**/
+     51,
   /**/

--
It is illegal for anyone to give lighted cigars to dogs, cats, and other
domesticated animal kept as pets.
		 [real standing law in Illinois, United States of America]

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

Mike Steed wrote:

> To clarify, are we talking about command-line support for
>
>   (a) completing environment variable names, or
>   (b) expanding environment variable names to their values?
>
> I was thinking of (a).  Vim already does (b), plus some special-case code
> for $HOME, $VIM, and $VIMRUNTIME.  I ask because it looks like the example
> above illustrates (b).
>
> Is (a) worth the extra code?

I thought we were talking about (a).  Mostly the command that you execute will
expand the variable to its value.

--
Engineers understand that their appearance only bothers other people and
therefore it is not worth optimizing.
				 (Scott Adams - The Dilbert principle)

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

On Mon, 10 Apr 2000, Bram Moolenaar wrote:

> Johannes Zellner wrote:
>
> > having
> >     :syntax region fred start=+.*fred+rs=s end=+fred+
> >     :hi fred cterm=blue
> >
> > why does this not match the following line ?
> >
> > blabla fred blabla
> >
> > :help syn-region says:
> >  The search for the end pattern starts at the start of the region.
> >  This implies that it can also match inside the start pattern!
>
> The documentation is wrong, the search for the end pattern starts only after
> the match with the start pattern.  Otherwise this wouldn't work:
>
>  :syn region someString start=/"/ end=/"/
>
> Now the question is if it should somehow be possible to find a match for the
> end pattern inside the match for the start pattern?  It could perhaps be
> useful in some situations.  Although you can probably do what you want with a
> "syn match" item then, since it's in a single line.  Perhaps we need an
> example of you were trying to do.

suppose I want to highlight a pattern (e.g. my e-mail address) in all files
of all filetypes w/o changing the original syntax files and without adding
a line in `mysyntax.vim' for each filetype.

I thought this could be possible by an autocommand which is triggered after
the syntax has been loaded. Something like

au BufReadPost * syntax region eMail start=+<johannes@...>+rs=s
end=+<johannes@...>+
hi eMail term=underline cterm=underline ctermfg=darkblue gui=underline
guifg=blue

The problem is that the pattern I want to add (here: my email) may occur
within an other syntax region (e.g. a comment.).

" e.g. in a .vim file
" (C) 1999 - 2000 by Johannes Zellner, <johannes@...>
"                                      ^^^^^^^^^^^^^^^^^^^^^^
"                                          highlight this

" does not work for the above case:
au BufReadPost * syntax match eMail +<johannes@...>+

" matches the above case but highlights all from the beginning of the line:
au BufReadPost * syntax match eMail +.*<johannes@...>+


maybe there's an easy solution, but I don't see it.


--
    Johannes

Le Mon, Apr 10, 2000 at 09:31:39PM +0200, Bram Moolenaar a écrit:
> > Over the weekend I spent some time planning an attack on the folding
> > feature, which I think I can implement over the next few weeks. As I worked
> > through the questions raised, various topics for discussion turned up. I'd
> > like to kick off that discussion.
>
> Don't bother implementing this, I'm already working on it.

In order to know what's going on, what dya think of launching
cvsdev.vim.org ? :)

It would permit virtually anything people want, even see the
latest dev in virtual editing etc...

	 Arnaud.

Robert Webb wrote:

> Some other ponderings about folds:
>
> - I can imagine two ways of showing folded lines.  One where the lines
> disappear completely and nothing is put in their place.  Some highlighting
> or special character somewhere is needed to indicate this.  And one where
> the lines are replaced by a single line indicating that there are folded
> lines.  This is easier, because it allows the user to possibly associate
> some text with the fold, and could display a "+" for clicking on to open it
> etc.  But sometimes it might be preferable not to have to see this extra
> line, eg if you want to see a whole lot of function headings together,
> without an extra line between each one taking up space.  Also, when the fold
> is open we don't want to see an extra line telling us that there is an open
> fold, so there still need to be a way to show the fold without taking up an
> extra line.

Well, although I can imagine situations where you don't want a closed fold to
show a line, it can be quite confusing.  And the line that replaces a closed
fold can contain the function heading, so in this case you don't need the line
to disappear.  I just implemented a 'foldtext' option, which is a
substitute-like specification.  The default is:

	     /\(\S.*\)/+-- \f lines: \1

The first part in between // is a regexp, which matches all text after the
indent.  The "\f" is replaced with the number of folded lines.  The "\1" is
replaced with the matched text, as in a substitue.  The line is truncated to
fit in the window, it won't wrap.

Since this is very flexible, would there still be a need for a fold to reduce
to zero lines?  This is extra work, so I need a reason to implement it.

> - Open folds could be shown by a "-" in the right hand column, which could
> be clicked to close the fold, but many folds could be nested starting on the
> same line couldn't they?  Then where would the special characters go?  Maybe
> nested folds should be restricted to be completely inside each other, so
> they can't start/end on the same lines?

I'm currently allowing nested folds to start (and end) on the same line.  This
is required for the nesting to work.  You can set 'foldlevel' to quickly set
the level of nested folds that are closed.  This is especially useful for
folding based on indent.  When the indent increases two 'shiftwidth's, the
nested fold then covers the same lines as fold it is in.

A single "-" in the rightmost column is hard to spot, especially when there
are wrapped lines.  It would be nice to see a whole column along the open
fold.  You can then also see where a fold ends.  A nested fold would do the
same in another column, so that you can see the nesting.  But, this takes
quite a bit of space on the screen, and can clutter up the display.  Perhaps
we can do something with highlighting.  Using the leftmost column would be
possible when there is an indent.  Oh, but preprocessor lines get in the
way...

This needs more thinking.  Perhaps sacrifying two columns to show the open
folds in the left margin is a good solution in situations where you can have a
wider window (e.g., in the GUI).  Something like this:

- /* comment for next function */
1  void
1 function_name(args)
1 {
-  /* comment 1 */
2  body_part_1
-  /* comment 2 */
2  body_part_2
1 }

The number indicates the fold level.  The "-" marks the start of a fold.
This works, since a fold is always at least two lines.  The margin would be
highlighted, if possible, to separate it from the text.

Another advantage of this is that clicking in the margin is unambigiously
a command open or close a fold.

> - Will it be possible to fold characters within a line?  I can imagine a
> special kind of folding for displaying man pages and the like, where we hide
> all the formatting characters (but use them for highlighting of course!).
> This would be a pattern-based kind of folding, and would involve lots of
> different patterns potentially, and no special character anywhere to
> indicate that the fold even exists.  It would be nice to be able to edit
> such a file too!  Maybe it could be implemented as a new kind of syntax
> highlighting, which rather than assigning a colour indicates that the
> characters should vanish altogether.

I wouldn't call this folding.  It's more like translating a sequence of bytes
in the file to characters on the screen.  Perhaps this can be combined with
implementing UTF-8, which also needs to recognize multi-byte sequences and
translate them into one or two character cells.  That's completely separate
from folding, which is good.

Editing such translated bytes could be done like the input-method: Either
on-the-spot (overlapping the text) or off-the-spot (on the command line).
Switching to Insert mode is probably sufficient to trigger the input method.
But, all this is for later!

--
I think that you'll agree that engineers are very effective in their social
interactions.  It's the "normal" people who are nuts.
				 (Scott Adams - The Dilbert principle)

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

Bram Moolenaar wrote:
> Allan Kelly wrote:
> > Hello, My wife and I are expecting a baby any day now [ =) ] and so I
> > am spending more time @ home than usual right now.
>
> Is that baby 1.0 or 2.0? :-)

   Must be baby number 1.0 - only someone who's not yet gone through those
first three months would be planning what to do in the 'spare' time
they'll have while at home after bringing the wife home :-)

   [10 months; just learned to crawl & making the most of it ;) ]

--
=====================- http://www.racaldefence.com/ -===================
   Neil Bird                      |
                                  |            This .signature is
     mailto:neil.bird@...  |          certified Y2K compliant

Arnaud Launay wrote:

> In order to know what's going on, what dya think of launching
> cvsdev.vim.org ? :)
>
> It would permit virtually anything people want, even see the
> latest dev in virtual editing etc...

And show people what mess I'm making at the moment?  No, I rather not do that.
I have plenty of work without showing this code to others.  I rather make it
first work as I think it's mostly OK, and then let other people have a look.
If I release it to early, I will end up spending a lot of time helping people
to make it run and discussions about things that aren't finished yet.

Don't worry, there will be plenty of room for changes between the first 6.0
alpha release and the 6.0 final release.

--
I learned the customs and mannerisms of engineers by observing them, much the
way Jane Goodall learned about the great apes, but without the hassle of
grooming.
				 (Scott Adams - The Dilbert principle)

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/

Bram Moolenaar wrote:
>
> Arnaud Launay wrote:
>
> > In order to know what's going on, what dya think of launching
> > cvsdev.vim.org ? :)
> >
> > It would permit virtually anything people want, even see the
> > latest dev in virtual editing etc...
>
> And show people what mess I'm making at the moment?  No, I rather not do that.
> I have plenty of work without showing this code to others.  I rather make it
> first work as I think it's mostly OK, and then let other people have a look.
> If I release it to early, I will end up spending a lot of time helping people
> to make it run and discussions about things that aren't finished yet.
>
> Don't worry, there will be plenty of room for changes between the first 6.0
> alpha release and the 6.0 final release.
>

Being in development myself, I very much agree with Bram's answer
above. If one wants to miss a whatever deadline, there is nothing
like having other people 'look at' and 'suggest improvements' to
the code not even firmly laid down. Patience!

---Zdenek

Le Tue, Apr 11, 2000 at 01:10:47PM +0200, Zdenek Sekera a écrit:
> Being in development myself, I very much agree with Bram's answer
> above. If one wants to miss a whatever deadline, there is nothing
> like having other people 'look at' and 'suggest improvements' to
> the code not even firmly laid down. Patience!

Who speaks of a deadline ? Here at work we had a deadline -- and
now we have enforced it of 4 weeks, so, deadline is something
that makes myself smiling. No, my point was just to see what
horrible code Bram could wrote when developping something :)

Also, code will be ready when code will be ready. Point.

	 Arnaud, oh, that's why it was "cvsdev" and not "cvs", too :)

Neil Bird wrote:
>
> Bram Moolenaar wrote:
> > Allan Kelly wrote:
> > > Hello, My wife and I are expecting a baby any day now [ =) ] and so I
> > > am spending more time @ home than usual right now.
> >
> > Is that baby 1.0 or 2.0? :-)
>
>   Must be baby number 1.0 - only someone who's not yet gone through those
> first three months would be planning what to do in the 'spare' time
> they'll have while at home after bringing the wife home :-)
>
>   [10 months; just learned to crawl & making the most of it ;) ]

<wildly off-topic>

baby 1.0, and we're having it at home!

Vim: the editor for all the family =)
(better not say 'the family editor', the pope might chase us! ;)

</wildly off-topic>

Anyway, sounds like the folding code is quite advanced. I'm looking forward
to seeing it and although I appreciate Bram's sentiments of keep it to
himself for now, I think that Z (whilst very good because it _looks_
like a fold!) is very dangerous due to ZZ possible errors. Personally I'd
love to map my (otherwise totally useless) CapsLock key to fold operations.
I wonder if that is possible? And what about those stupid windows keys?

al.

--

  # Allan Kelly                                http://www.plotsearch.co.uk
  # (+44) (0)131 524 8500
  # allan.kelly@....     ..
  # /Software Engineer/i            . .    .    . .
  # ------------------------------   *      . .     .    . .
  # "If you are a Visual Basic programmer,   *       . .     .
  #  these details are none of your business."        *       .  . .
  # Mr Bunny's Guide to Active X, by Carlton Egremont III      *     . .
  # ------------------------------      vi: set noet tw=80 sts=4 ts=8  : .

On Tue, 11 Apr 2000, Allan Kelly wrote:

> <wildly off-topic>
>
> baby 1.0, and we're having it at home!
congratulations!
> Vim: the editor for all the family =)
> (better not say 'the family editor', the pope might chase us! ;)
>
> </wildly off-topic>
>
> Anyway, sounds like the folding code is quite advanced. I'm looking forward
> to seeing it and although I appreciate Bram's sentiments of keep it to
> himself for now, I think that Z (whilst very good because it _looks_
> like a fold!) is very dangerous due to ZZ possible errors. Personally I'd
> love to map my (otherwise totally useless) CapsLock key to fold operations.
> I wonder if that is possible? And what about those stupid windows keys?

you've to tell your Xserver about them:

! -*- .xmodmaprc -*-
keycode 115 = 0200
keycode 116 = 0200

xmodmap .xmodmaprc

and you'll get octal 200 if you type one of the windows keys.
(115/116 might vary, you've to check this with xev).
I use these as the escape character in `screen'.

If you're on console you can put these translations
somewhere in you default.keytab file.

naturally you can also make CapsLock sending any event this way.
- use xev to see what CapsLock generates (it's 66 here)
- use `keycode 66 = <whatever>' with xmodmap

--
    Johannes

Le Tue, Apr 11, 2000 at 11:43:43AM +0100, Allan Kelly a écrit:
> <wildly off-topic>
> baby 1.0, and we're having it at home!

So now you're ready not to sleep for weeks :)

> I wonder if that is possible? And what about those stupid windows keys?

Problems of w$ keys is that not everybody have them, and it will cause problems
on machine which don't have them. Maybe, a : command should be better...

	 Arnaud.

Hello,

having
     fred
     fred
     fred
highlighting the column of f's with <c-v> followed by 10Ia<esc> gives
     afred
     afred
     afred
I would have expected
     aaaaaaaaaafred
     aaaaaaaaaafred
     aaaaaaaaaafred

because visual.txt says:
If you want to give a count to the command, do this just before typing the
operator character: "v{move-around}3>" (move lines 3 indents to the right).

--
    Johannes

Johannes Zellner wrote:
> If you want to give a count to the command, do this just before typing
> the operator character: "v{move-around}3>" (move lines 3 indents to the
> right).

   I think I agree, although I can see Barm coming out with a Very Good
Reason why it doesn't :-)

   On that note, though, how come 'I' works across <C-V> but not <S-V>?

--
=====================- http://www.racaldefence.com/ -===================
   Neil Bird                      |
                                  |            This .signature is
     mailto:neil.bird@...  |          certified Y2K compliant

> From: Johannes Zellner <johannes@...>
>
> suppose I want to highlight a pattern (e.g. my e-mail address) in all files
> of all filetypes w/o changing the original syntax files and without adding
> a line in `mysyntax.vim' for each filetype.

I use the following to highlight a variety of todo items:

" Todo/DEBUG items in comments:
autocmd BufNewFile,BufRead * if exists("b:current_syntax")
autocmd BufNewFile,BufRead *    exe 'syn keyword '.b:current_syntax.'Todo
contained TODO FIXME XXX DEBUG Debug Todo todo ATTENTION kludge Kludge KLUDGE'
autocmd BufNewFile,BufRead *    exe 'syn match '.b:current_syntax.'Todo
contained "!!!!*\|????*"'
autocmd BufNewFile,BufRead * endif

If your e-mail name will always appear in comments, you could use
this to highlight it using the Todo highlight group.  There are
highlight groups used by some syntax files you could do the same
with - xSpecial, xStringError - to get highlighting in strings,
but it would be much less universal.

A more complete, albiet slower and more complicated, solution would
be to write a function that captures the output of the ":syntax"
command, clears the syntax, and rebuilds it using the captured output,
with the addition of a "contains=eMail" on every syntax item.

Or you could turn hlsearch on and "/johannes@..."....


--
Free High Speed DSL Access:
http://in.winfire.com/s/isapiEng.dll/wf.exe?cmd=rl&452,180045277&wf.exe
______________________________________________________________________
                                                     ________  ______
Stephen P. Wall        Redcom Laboratories, Inc.   /  __   /\/  ___/\
Steve_Wall@...  One Redcom Center       ___/  /\/  /_/  /\__\/
(716) 924-7550         Victor, NY 14564       /_____/ /_______/ /
x300                   USA                    \_____\/\_______\/

On Tue, 11 Apr 2000, Stephen P. Wall wrote:

> > From: Johannes Zellner <johannes@...>
> >
> > suppose I want to highlight a pattern (e.g. my e-mail address) in all files
> > of all filetypes w/o changing the original syntax files and without adding
> > a line in `mysyntax.vim' for each filetype.
>
> I use the following to highlight a variety of todo items:
>
> " Todo/DEBUG items in comments:
> autocmd BufNewFile,BufRead * if exists("b:current_syntax")
> autocmd BufNewFile,BufRead *    exe 'syn keyword '.b:current_syntax.'Todo
> contained TODO FIXME XXX DEBUG Debug Todo todo ATTENTION kludge Kludge KLUDGE'
> autocmd BufNewFile,BufRead *    exe 'syn match '.b:current_syntax.'Todo
> contained "!!!!*\|????*"'
> autocmd BufNewFile,BufRead * endif
not bad. I'll try this. thanks.

--
    Johannes

On Tue, Apr 11, 2000 at 10:39:57AM +0100, Neil Bird wrote:
> Bram Moolenaar wrote:
> > Allan Kelly wrote:
> > > Hello, My wife and I are expecting a baby any day now [ =) ] and so I
> > > am spending more time @ home than usual right now.
> >
> > Is that baby 1.0 or 2.0? :-)
>
>   Must be baby number 1.0 - only someone who's not yet gone through those
> first three months would be planning what to do in the 'spare' time
> they'll have while at home after bringing the wife home :-)
>
>   [10 months; just learned to crawl & making the most of it ;) ]

*chuckle* Well, this is David Harrison Jr. here. I started to implement my
vision of folding based on, then, Vim 5.3.  Then came a new baby...
I second the motion that it is baby 1.0 for them.  The only time
I seem to have to "work" on folding is in my dreams nowadays.  :-)

I based mine off of the syntax highlighting concept, as I believe it is a
powerful one indeed.  I am seeing this idea surface from others now, too.


--David Harrison Jr.
dharriso@...

On Tue, 11 Apr 2000, Johannes Zellner wrote:

> On Tue, 11 Apr 2000, Stephen P. Wall wrote:
>
> > > From: Johannes Zellner <johannes@...>
> > >
> > > suppose I want to highlight a pattern (e.g. my e-mail address) in all
files
> > > of all filetypes w/o changing the original syntax files and without adding
> > > a line in `mysyntax.vim' for each filetype.
> >
> > I use the following to highlight a variety of todo items:
> >
> > " Todo/DEBUG items in comments:
> > autocmd BufNewFile,BufRead * if exists("b:current_syntax")
> > autocmd BufNewFile,BufRead *    exe 'syn keyword '.b:current_syntax.'Todo
> > contained TODO FIXME XXX DEBUG Debug Todo todo ATTENTION kludge Kludge
KLUDGE'
> > autocmd BufNewFile,BufRead *    exe 'syn match '.b:current_syntax.'Todo
> > contained "!!!!*\|????*"'
> > autocmd BufNewFile,BufRead * endif
> not bad. I'll try this. thanks.

but it restricts me to groups which were defined
to be contained in b:current_syntax.'Comment'

--
    Johannes

> From: Bram Moolenaar <Bram@...>
>
> Well, although I can imagine situations where you don't want a closed fold to
> show a line, it can be quite confusing.  And the line that replaces a closed
> fold can contain the function heading, so in this case you don't need the
line
> to disappear.  I just implemented a 'foldtext' option, which is a
> substitute-like specification.  The default is:
>
> 	    /\(\S.*\)/+-- \f lines: \1
>
> The first part in between // is a regexp, which matches all text after the
> indent.  The "\f" is replaced with the number of folded lines.  The "\1" is
> replaced with the matched text, as in a substitue.  The line is truncated to
> fit in the window, it won't wrap.

What if I want the text on the fold line to come from the second line
of folded text?  Will you allow a multi-line regex?

	 /^.*$^\s*\(.*\)$/*-- \f lines: \1/

Or a line number spec?

	 2/\(\S.*\)/+-- \f lines: \1/  2nd line of fold
	 $/^\s*\(\S*\)/+-- \f lines: \1/  last line of fold

How will this text be highlighted?  Using it's normal highlighting,
or a new Fold highlighting?


> This needs more thinking.  Perhaps sacrifying two columns to show the open
                                      ^^^^^^^^^^  sacrificing
> folds in the left margin is a good solution in situations where you can have
a
> wider window (e.g., in the GUI).  Something like this:
>
> - /* comment for next function */
> 1  void
> 1 function_name(args)
> 1 {
> -  /* comment 1 */
> 2  body_part_1
> -  /* comment 2 */
> 2  body_part_2
> 1 }
>
> The number indicates the fold level.  The "-" marks the start of a fold.
> This works, since a fold is always at least two lines.  The margin would be
> highlighted, if possible, to separate it from the text.

Those who use numbering sacrifice 8 columns to do so, so I don't think
sacrificing two columns to use folding is unreasonable.  You could
also use a number to mark the start of a fold, and a vertical bar to
mark the body.  This way, you still see the fold level when the fold
is closed.  Maybe add a '\l' to the foldtext option.

Will you use the NonText highlight group for this column, or LineNr, or
create a new group?

What about navigation?  Motion command to go to the start/end of the
current/next fold region.  Use wrapscan when at start/end of file?

	 char  action in Normal mode
	 ----------------------------------------
	 [|  cursor to N previous start of a fold region
	 ]|  cursor to N next start of a fold region

--
Free High Speed DSL Access:
http://in.winfire.com/s/isapiEng.dll/wf.exe?cmd=rl&452,180045277&wf.exe
______________________________________________________________________
                                                     ________  ______
Stephen P. Wall        Redcom Laboratories, Inc.   /  __   /\/  ___/\
Steve_Wall@...  One Redcom Center       ___/  /\/  /_/  /\__\/
(716) 924-7550         Victor, NY 14564       /_____/ /_______/ /
x300                   USA                    \_____\/\_______\/

> From: Johannes Zellner <johannes@...>
>
> but it restricts me to groups which were defined
> to be contained in b:current_syntax.'Comment'
>

Yes.  Almost half of the syntax files include a Todo item.
And as I said, it will only be in comments.  Maybe you could implement
a new syntax keyword, "containedall":

	 syntax match eMail "johannes@..." containedall

Would force eMail to be contained by all other syntax groups, whether
they have a "contains=" option or not.  Don't know if Bram would
want to include such a thing - it's use it quite narrow.  Would there
be a more general way to implement something like this?

	 syntax match eMail "johannes@..." supercedes=@ALL

with "supercedes" being a list of syntax items which this item will
supercede, even if the other syntax has already started.  problems -
should the superceded syntax resume after the superceding one ends,
or should it just be ended, or should the code track both syntaxes
simultaneously, and "do the right thing"?  Could get quite complicated,
multiple "supercedes" could result in tracking several syntaxes
simultaneously.  Could restrict to only one supercede active at a time,
ie, you cannot supercede a syntax item that has the "supercede" option.
Again, though, are there enough practical applications of such an item
to make implementation worthwhile?

--
Free High Speed DSL Access:
http://in.winfire.com/s/isapiEng.dll/wf.exe?cmd=rl&452,180045277&wf.exe
______________________________________________________________________
                                                     ________  ______
Stephen P. Wall        Redcom Laboratories, Inc.   /  __   /\/  ___/\
Steve_Wall@...  One Redcom Center       ___/  /\/  /_/  /\__\/
(716) 924-7550         Victor, NY 14564       /_____/ /_______/ /
x300                   USA                    \_____\/\_______\/