From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17323 invoked from network); 6 Mar 1997 19:39:06 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by coral.primenet.com.au with SMTP; 6 Mar 1997 19:39:06 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id OAA25740; Thu, 6 Mar 1997 14:28:23 -0500 (EST) Resent-Date: Thu, 6 Mar 1997 14:28:23 -0500 (EST) From: (Zoltan T. Hidvegi) Message-Id: <9703061833.AA17252@lotto.fishkill.ibm.com> Subject: Re: zle_refresh patch 2 In-Reply-To: <19970306050339.13035.qmail@primenet.com.au> from "gwing@primenet.com.au" at "Mar 6, 97 04:03:39 pm" To: gwing@primenet.com.au Date: Thu, 6 Mar 1997 13:32:57 -0500 (EST) Cc: schaefer@nbn.com, zsh-workers@math.gatech.edu X-Mailer: ELM [version 2.4ME+ PL31 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"wmfzD2.0.3I6.Nhn7p"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2964 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu gwing@primenet.com.au wrote: > Bart Schaefer wrote: > :I think you can continue patching 3.0.3-test4 as long as you don't make > :reference to zle globals in non-zle .c files. Zoltan? Yes, that's fine. But I only keep and test the 3.1 source tree, 3.0 is in the RCS file only. What I do, is I patch 3.1, and if it works, I merge it to the 3.0 branch. So a 3.1 patch it is a bit more convinient for me, but it is not a big difference. > OK, I accidently killed my old source, but have reapplied patches > 2865(me), 2956(Bart), 2957(Zoltan) to 3.0.3-test4 > I didn't apply 2866(2868) because I assumed 2956 superceded it. > Does anyone know if there were any others? Is it in your Changelog, Zoltan? That's all I have in my ChangeLog. I did not yet changed tsetcap() (this is in zle_misc.c for 3.0 and in prompt.c in 3.1). I assume that the condition at the very beginning of tsetcap() should be if (termok && tcstr[cap]), is that right? Does it work in shortterm mode? I do not know why was this shortterm/SINGLELINEZLE condition was there before. I also think it is fine for zle to act as if single_line_zle were set when lines < 3. This is a reasonable behaviour, and if normal zle requires a lot of extra code to handle this it does not worth it. I also remember having problems with the statusline when the buffer was more than a screen high (e.g. start editing a large file with zed, and use describe-key-briefly to find a meaning of a key, and the screen will be messed up). Zoltan