From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9184 invoked from network); 10 May 1999 08:22:36 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 May 1999 08:22:36 -0000 Received: (qmail 28082 invoked by alias); 10 May 1999 08:22:19 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6244 Received: (qmail 28075 invoked from network); 10 May 1999 08:22:18 -0000 Message-Id: <9905100753.AA33639@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) 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 "Sat, 08 May 1999 16:43:27 DFT." <199905082343.QAA08737@bebop.clari.net> Date: Mon, 10 May 1999 09:53:16 +0200 From: Peter Stephenson I've applied both the other history patches, and it does exactly what I was hoping, thanks. Wayne Davison wrote: > I'm torn on the issue, because sometimes I want to up-arrow through > the total history, and sometimes I just want to press ^P and run the > last command that I ran in this window, no exceptions. You can setopt histverify and edit the line produced by !!, of course, but I don't claim that's a perfect solution. > I'd be interested in suggestions for how we can let the user choose > between local-history and full-history movement. Perhaps a toggle > command? Or a bindable prefix (so I can have ^P ignore shared > history, and Up-Arrow include it)? I like this idea. You mean something like a toggle, either for the next command only or permanently? That might work. You could then have a zle widget up-line-or-local-history { zle toggle-local-history zle up-line-or-history } if it works on the next command, or up-line-or-local-history { integer savnum=$NUMERIC NUMERIC=1 zle toggle-local-history NUMERIC=$savnum zle up-line-or-history NUMERIC=0 zle toggle-local-history } if it was a permanent state change. Hmmm, it might be a good idea to make `zle widget num' override the value of $NUMERIC with num when calling a widget. > > I'd like to suggest that any zle reference to the history [...] > > causes the newly imported stuff to be visible. > > I think that some zle commands, such as accept_and_infer_next_ > history, should remain unaffected by foreign commands. OK, I hadn't thought about that one, it was really only up/down commands that crossed my mind. > I think you've misinterpreted what's going on. The current code > waits until the command _finishes_ before adding it to the history > file. I did this because the extended_history format contains the > finish time of the command. I also don't like this delay in adding > the command, though, so I think we add the command after it is typed, > and just live with the fact that all the finish times will be the > same as the start times when using incremental_append_history (which > is used by shared_history). I don't quite understand how that was making the difference. The command was finishing in one window; all my comments about how the history list got retrieved in the other window presupposed I hadn't done anything else in the first window, i.e. its command was definitely saved. Is the point that reading the foreign history happened at the same time as writing the local one, so that the line saved from the first window was getting read later than I expected in the second? though I don't quite believe that, looking at the old code. Perhaps on the question of incremental_append_history/append_history it would be a good idea to ask on the users list if they like the idea of the existing option being altered. The effect is different, even if you aren't using shared history, however. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy