From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13095 invoked from network); 8 May 1999 14:25:55 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 8 May 1999 14:25:55 -0000 Received: (qmail 8021 invoked by alias); 8 May 1999 14:25:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6238 Received: (qmail 8014 invoked from network); 8 May 1999 14:25:42 -0000 Message-Id: <9905081401.AA40488@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: history improvements for 3.1.5-pws-17 and 3.0.6-pre-2 In-Reply-To: "Wayne Davison"'s message of "Fri, 07 May 1999 19:50:52 DFT." <199905080250.TAA02805@bebop.clari.net> Date: Sat, 08 May 1999 16:01:21 +0200 From: Peter Stephenson Wayne Davison wrote: > Appended is the history improvements for pws-17 that I mentioned in > zsh-workers 6218. Thanks, this will appear in pws-18. One addition in the patch below: share_history is set in ksh emulation. Some comments on share_history (which is the one I've played about with most): actually, it doesn't emulate ksh at the moment, because only a few commands cause the history from any other instance of the shell to be used. I know this is how it's documented, but I find the behaviour a bit confusing, since after I've typed something in one shell, and hit return in another shell, I expect to be able just to use up-line-or-history to get to what's in the other shell --- otherwise I might just as well use an explicit fc -RI and the option's not much use, or so I've been finding on rather limited experience so far. I presume that the real problem is numbering of bang-history references, and I agree it's correct to be careful in that case. However, I'd like to suggest that any zle reference to the history (apart from expansion of lines like !*, of course, but that's done internally via the lexer so shouldn't cause problems as an exception) causes the newly imported stuff to be visible. I don't think this is likely to cause confusion, since you always see the line before doing anything with it --- in fact, in my case it would definitely help eliminate confusion, and also it would make the behaviour more ksh-like. Next point --- there is another slight confusion, partly at least as a knock on effect of this. If I type something in shell 1, I know it won't be imported until after the next line in shell 2 is finished, and won't show up until after the next history reference. So I type `history'. As explained above, I find this a bit clumsy anyway, but the point here is that for some reason due to the internal handling it's not enough to make what I just typed in shell 1 appear (even if I unset histnostore, which I thought might have had an effect). It only happens after I've typed a new command in shell 2, which can't be a history command or a blank line, and then after that I have to do something to get the commands to show up. Ideally for sharing history, I'd like to be able just to hit return (to do the reading) then up (to allow the new commands to show up) to get what I just typed in the other shell, just as happens in ksh. Hope that's possible. --- Src/options.c.newhist Sat May 8 14:31:51 1999 +++ Src/options.c Sat May 8 15:27:16 1999 @@ -181,7 +181,7 @@ {NULL, "restricted", OPT_SPECIAL, RESTRICTED}, {NULL, "rmstarsilent", OPT_BOURNE, RMSTARSILENT}, {NULL, "rmstarwait", 0, RMSTARWAIT}, -{NULL, "sharehistory", 0, SHAREHISTORY}, +{NULL, "sharehistory", OPT_KSH, SHAREHISTORY}, {NULL, "shfileexpansion", OPT_EMULATE|OPT_BOURNE, SHFILEEXPANSION}, {NULL, "shglob", OPT_EMULATE|OPT_BOURNE, SHGLOB}, {NULL, "shinstdin", OPT_SPECIAL, SHINSTDIN}, -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy