Subject: vim and b18
From: [email-masked] (Larry Hall)

29 Sep 1997 07:11:20 -0700
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_875555360==_"
To: [email-masked]
Cc: [email-masked]

--=====================_875555360==_
Content-Type: text/plain; charset="us-ascii"

Hello fellow gnu-win32 users,

I have asked about this problem before on this list and received no feedback
so perhaps I'm the only one experiencing it.  Nevertheless, since I have
created a patch for the problem, I thought others might be interested (or
even better, explain to me a better way to solve this problem).  The problem
I had was using a locally compiled version of vim (5.0k and 5.0m) in the
b18 environment.  While vim ran with Chris Faylor's patch, I found that 
scrolling down (CTRL-D), searching down (/<something> and "n"), and even 
moving down a line when I was at the bottom of the screen would scroll the 
command line of vim as well.  Many times the text of the command line would
be overwritten by the source from the file that displayed on that line so 
the problem would look like it was sporadic.  It was most noticeable when the
ruler was used.  However, with a little investigation, I noticed that it
ALWAYS occurred but was only noticeable when text from the source file did
not overwrite the text from the command line.  I have created a patch which
fixes this problem for me.  My guess is it is not optimal, since it forces
the command line to be cleared in all these cases.  However, it was unclear
exactly what was causing this problem so this is the best solution I could
find.  It works fine for me and does not appear to affect performance to any
noticeable extent.  Suggestions from others on a better way to fix this are 
welcome.  

If you notice problems similar to what I describe, you may want to try this
patch.  I'm, using it on vim-5.0k but it should work through 5.0m at least.
My configuration is NT 4.0 + SP3 running b18 with an updated DLL from 
Sergey (circa 7/23).  I'm also using ncurses 1.9.9g and the slightly modified 
linux termcap entry (as included).  If anyone else finds this useful or has
any comments, I'd like to know.  

Thanks,

Larry Hall                              [email-masked]
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02181 

PS - For those who are curious, the unmodified source compiles, links, and 
runs fine WITHOUT THIS PATCH on linux (2.0.27 kernel).

--=====================_875555360==_
Content-Type: text/plain; charset="us-ascii"

#### ANSI console types
#

# This entry is good for the 1.1.47 version of the Linux console driver.
#
# It assumes that you want A_PROTECT mapped to the alternate character set
# mode that permits IBM ROM characters to be displayed (this is the assumption
# used by ncurses version 1.9 and after, in order not to collide with the
# internationalization attribute values specified in the XSI Curses standard).
#
# We use \E11m for rmacs rather than \E12m so the acsc string can use the ROM
# graphics for control characters such as the diamond, up arrow and down-arrow.
# This trick could work with other Intel consoles like the att6386 and pc3.
#
# Note: there are numerous broken linux entries out there, which didn't screw
# up BSD termcap but hose ncurses's smarter cursor-movement optimization.
# One common pathology is an incorrect tab length of 4.  Also note that the 
# hpa=\E[%dG/vpa=\E[%dd capabilities seem not to be reliable.  To reproduce
# the bug, re-introduce them and run worm -T 200 212 from the ncurses
# test suite, save the trace, then worm -N -T 200 212.  Observe that the first
# run fails to properly delete some worm segments, then diff the trace files.
#
# From: Eric S. Raymond <[email-masked]> 23 July 1995
linux|linux console:\
	:am:bs:eo:hs:mi:ms:ut:xo:\
	:Co#8:co#80:it#8:li#25:pa#64:\
	:AB=\E[4%p1%dm:AF=\E[3%p1%dm:\
	:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:F1=\E[23~:F2=\E[24~:\
	:F3=\E[25~:F4=\E[26~:F5=\E[28~:F6=\E[29~:F7=\E[31~:\
	:F8=\E[32~:F9=\E[33~:FA=\E[34~:IC=\E[%d@:K2=\E[G:\
	:S2=\E[11m:S3=\E[10m:Sb=\E[%+(m:Sf=\E[%+^^m:\
	:ac=`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~q\304r\362s_t\303u\264v\301w\302x\263y\371z\372{\373|\374}\375~\376.\031-\030\054\021+^P0\333:\
	:ae=\E[10m:al=\E[L:as=\E[11m:bl=^G:cd=\E[J:ce=\E[K:\
	:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:\
	:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ei=\E[4l:ho=\E[H:\
	:ic=\E[@:im=\E[4h:k1=\E[[A:k2=\E[[B:k3=\E[[C:\
	:k4=\E[[D:k5=\E[[E:k6=\E[17~:k7=\E[18~:k8=\E[19~:\
	:k9=\E[20~:k;=\E[21~:kD=\E[3~:kI=\E[2~:kN=\E[6~:\
	:kP=\E[5~:kb=^H:kd=\E[B:kh=\E[1~:kl=\E[D:kr=\E[C:\
	:ku=\E[A:le=^H:mb=\E[5m:md=\E[1m:me=\E[0;10m:\
	:mr=\E[7m:nd=\E[C:nw=^M^J:op=\E[37;40m:r1=\Ec:rc=\E8:\
	:..sa=\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;%?%p7%t;8%;%?%p8%t;11%;%?%p9%t;11%;m:\
	:sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\
	:u6=\E[%d;%dR:u7=\E[6n:u8=\E[?6c:u9=\E[c:ue=\E[24m:\
	:up=\E[A:us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:\
	:vi=\E[?25l:
linux-mono|Linux console, no color:\
	:Co@:pa@:\
	:AB@:Sb@:Sf@:tc=linux:

--=====================_875555360==_
Content-Type: text/plain; charset="us-ascii"

--- screen.orig	Sun Sep 28 22:21:57 1997
+++ screen.c	Sun Sep 28 22:36:36 1997
@@ -314,6 +314,18 @@
 	type = NOT_VALID;
     }
 
+    /* I don't know why but downward searches, scrolling, or single line 
+     * moves requires the command line to be cleared, otherwise we run the
+     * risk of seeing any text on the command line scrolled too.  Some of
+     * the text may be overwritten by text from the new source line but 
+     * anything that isn't replaced by new source will remain and make 
+     * things look ugly.  This only happens for the Cygnus environment on
+     * Windows platforms.  I'm not sure why...
+     */
+#ifdef __CYGWIN32__
+    clear_cmdline = 1;
+#endif
+
     if (clear_cmdline)		/* first clear cmdline */
     {
 	check_for_delay(FALSE);

--=====================_875555360==_
Content-Type: text/plain; charset="us-ascii"

Larry Hall                              [email-masked]
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02181                             

--=====================_875555360==_--

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".