From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4246 invoked from network); 1 Jun 2000 04:56:20 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Jun 2000 04:56:20 -0000 Received: (qmail 3215 invoked by alias); 1 Jun 2000 04:56:03 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11701 Received: (qmail 3207 invoked from network); 1 Jun 2000 04:56:01 -0000 From: "Bart Schaefer" Message-Id: <1000601045533.ZM29369@candle.brasslantern.com> Date: Thu, 1 Jun 2000 04:55:33 +0000 In-Reply-To: <000531170017.ZM27165@candle.brasslantern.com> Comments: In reply to "Bart Schaefer" "Re: BUG: vared in function" (May 31, 5:00pm) References: <000531170017.ZM27165@candle.brasslantern.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Zsh Workers Subject: Re: BUG: vared in function MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 31, 5:00pm, Bart Schaefer wrote: } Subject: Re: BUG: vared in function } } On May 31, 11:28pm, Peter Stephenson wrote: } > Subject: Re: BUG: vared in function } > Peter Stephenson wrote: } > > Bernd Eggink wrote: } > > > Argh... } > > > } > > > # t } > > > vared -cp "Aha: " BLAH } > > > } > > > % t } > > > t:vared:2: ZLE not enabled } > > > } > > > This breaks lots of my scripts! } } This is happening because of my bug report to the effect that vared was } improperly munging the TTY settings in an interactive shell that had ZLE } explicitly turned off (as e.g. inside and emacs shell buffer). } } I don't know how that interacts with Peter's patch (I'll try it later when } I get home). I should have been able to tell by looking closely at the patch, but this re-breaks things when interactive in an emacs buffer without doing anything new and useful for vared when not interactive. In addition to the bug I previously mentioned: } If you're going to pull this stuff out into a function, you need three } return states, not two. There's also a potential too-early return from bin_vared() a few lines after the call to openttyspecially(), where `if (zleactive)' is tested, and several more below that. Can't just move the place where the tty gets opened like that. Peter had asked: } > I don't think there's any good reason why zle shouldn't be enabled } > especially. } } In fact, what about this? If it works for read, shouldn't it work for } vared? The difference is that `read' tests specifically for emacs-ness and does not play with the tty settings in that case. Running `vared' inside an emacs buffer is the moral equivalent of running `vi' in one; it simply can't work at all when it can't drive the editing itself. You could ALMOST make `vared -c' work, but for any variable that already has a value emacs is going to treat the old value as part of the prompt. Given all of this, let's NOT use 11698, and instead use this: Index: Src/Zle/zle_main.c =================================================================== @@ -743,7 +743,7 @@ char *p1 = NULL, *p2 = NULL; FILE *oshout = NULL; - if (unset(USEZLE)) { + if ((interact && unset(USEZLE)) || !strcmp(term, "emacs")) { zwarnnam(name, "ZLE not enabled", NULL, 0); return 1; } Even this is not totally satisfactory, because modern versions of emacs export TERM=dumb and EMACS=t rather than TERM=emacs. However, TERM=emacs is the canonical way to tell zsh it's in an emacs buffer, so I've had this in my .zshrc for a while now: case ${TERM:-dumb} in emacs|dumb) [[ $EMACS = t ]] || return 0 TERM=emacs export EDITOR=emacs stty -onlcr -echo ttyctl -f # Doesn't really do any good ;; eterm) TERM=vt100 ;; esac -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net