* history related suggestions @ 1999-06-15 13:10 Kiddle, Oliver 1999-06-15 15:27 ` Peter Stephenson 1999-06-16 8:19 ` history related suggestions (plus bug reports) Bart Schaefer 0 siblings, 2 replies; 6+ messages in thread From: Kiddle, Oliver @ 1999-06-15 13:10 UTC (permalink / raw) To: 'zsh-workers@sunsite.auc.dk' I've finally got around to trying out Wayne's recent history extensions (see msgs 6218, 6236 and 6255) and have a few suggestions. I'm not convinced by the zle set-local-history system for toggling between local and shared history. I (and I would think most people) will bind one set of keys to shared history operations and another set to local ones rather than binding a key to toggle the history mode. With argument handling hopefully being added to zle widgets (which I think is a great idea), I think it would be better to ditch set-local-history and add an option to each of the history related widgets specifying whether to use shared or local history. Along with this, I would suggest that parameter expansion be done on the zle widget arguments each time the widget is run. This would allow users to do: bindkey '^[[A' up-line-or-history '$history_toggle' and then change the $history_toggle variable to select between local and shared history. My second suggestion is that the history items imported when zsh first runs (if SAVEHIST is set) should be marked as foreign. What I would also like is if these were numbered so that the most recent one is the same as $HISTSIZE. This would mean that when I first run zsh, the first command I type would be number 1, not 200. I'm more likely to recall it than one in my saved history and !1 is less typing than !200. Ideally, what would be nice is if the numbers of commands between two versions of zsh running at the same time would correspond but I imagine that it wouldn't be easy to implement and would cause a few problems. Oliver Kiddle ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: history related suggestions 1999-06-15 13:10 history related suggestions Kiddle, Oliver @ 1999-06-15 15:27 ` Peter Stephenson 1999-06-16 8:19 ` history related suggestions (plus bug reports) Bart Schaefer 1 sibling, 0 replies; 6+ messages in thread From: Peter Stephenson @ 1999-06-15 15:27 UTC (permalink / raw) To: 'zsh-workers@sunsite.auc.dk' "Kiddle, Oliver" wrote: > I'm not convinced by the zle set-local-history system for toggling between > local and shared history. I (and I would think most people) will bind one > set of keys to shared history operations and another set to local ones > rather than binding a key to toggle the history mode. You're supposed to use a widget function rather than bind it directly. (What's happened to the manual entry for set-local-history in the zle documentation? It doesn't seem to say anywhere how it works.) this-with-local-history() { local savnum=$NUMERIC NUMERIC=1 zle set-local-history NUMERIC=$savnum zle the-normal-this-command NUMERIC=0 zle set-local-history } zle -N this-with-local-history bindkey '...' this-with-local-history (this will all become smoother when argument handling becomes standardised anyway). > With argument handling > hopefully being added to zle widgets (which I think is a great idea), I > think it would be better to ditch set-local-history and add an option to > each of the history related widgets specifying whether to use shared or > local history. It might be a nice idea to add this. > Along with this, I would suggest that parameter expansion be > done on the zle widget arguments each time the widget is run. This would > allow users to do: > bindkey '^[[A' up-line-or-history '$history_toggle' > and then change the $history_toggle variable to select between local and > shared history. That sort of thing should certainly be done inside functions. up-line-or-history-switch() { zle up-line-or-history $history_toggle } zle -N up-line-or-history-switch bindkey '^[[A' up-line-or-history-switch Extra levels of expansion tend to make things a bit of a mess, and in my experience you always get to the point where you need the extra flexibility of a function anyway. (Cf. S. Wischnowsky, Collected New Completion Mailings, Zsh Workers Mailing List 1999, passim.) -- Peter Stephenson <pws@ibmth.df.unipi.it> Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: history related suggestions (plus bug reports) 1999-06-15 13:10 history related suggestions Kiddle, Oliver 1999-06-15 15:27 ` Peter Stephenson @ 1999-06-16 8:19 ` Bart Schaefer 1999-06-16 20:46 ` PATCH: pws-22: history -r fix Wayne Davison 1999-06-16 21:59 ` history related suggestions (plus bug reports) Wayne Davison 1 sibling, 2 replies; 6+ messages in thread From: Bart Schaefer @ 1999-06-16 8:19 UTC (permalink / raw) To: zsh-workers On Jun 15, 2:10pm, Kiddle, Oliver wrote: } Subject: history related suggestions } } My second suggestion is that the history items imported when zsh first runs } (if SAVEHIST is set) should be marked as foreign. Oh, I don't like that idea at all. Maybe I'm just funny, but a lot of the time when I start a shell the first thing I do is run a command searched from the history of my last session. That's probably because the only shells that I frequently start and stop are those to remote systems where I only run a few commands (I tend to stay logged in to a couple of xterms for weeks when using the local console). Nevertheless it would bug me to have to use a different search command to find those. Such a change could also cause confusion for people who are upgrading from 3.0 ("Where'd my history go?!?"). } What I would also like is if these were numbered so that the most } recent one is the same as $HISTSIZE. This would mean that when I first } run zsh, the first command I type would be number 1, not 200. How would you refer in bang-syntax to the commands that precede 1 ? They can't be given negative numbers; !-10 already means ten commands before the current command. } I'm more likely to recall it than one in my saved history and !1 is } less typing than !200. Ideally, what would be nice is if the numbers } of commands between two versions of zsh running at the same time would } correspond but I imagine that it wouldn't be easy to implement and } would cause a few problems. You could accomplish that by completly flushing and reloading the history from the shared file every time that the file changes, starting over at 1 with the numbering each time -- but I think you'd rapidly find that it was more annoying than useful: the number that a command had a moment ago would no longer be the number it has now, so your reference to !4 might get the wrong thing. As long as we're on the subject ... the HIST_EXPIRE_DUPS_FIRST option has some bad side-effects involving the {accept-and,}infer-next-history zle commands. One things start falling out of the middle of the history, it is possible to refer to a command whose logical next no longer exists, so those commands retrieve the wrong thing. On a possibly-related note, "history -r" seems to be broken now: zagzig<7> history 1 setopt | grep hist 3 echo foobar 4 setopt histexpiredupsfirst 5 typeset | grep HIST 6 HISTSIZE=6 zagzig<8> !-3:p typeset | grep HIST zagzig<9> !-2:p history zagzig<10> hh fc: no events in that range zagzig<11> alias hh hh='history -r -$HISTSIZE | more' zagzig<12> echo $HISTSIZE 6 zagzig<13> exit (Now start over) zagzig<1> hh fc: bad history number: 1 zagzig<2> hh fc: bad history number: 1 zagzig<2> echo this is a test this is a test zagzig<3> hh fc: no events in that range zagzig<4> 3.0.6-pre-4 doesn't suffer from this problem, so it must have something to do with the new history extensions. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* PATCH: pws-22: history -r fix 1999-06-16 8:19 ` history related suggestions (plus bug reports) Bart Schaefer @ 1999-06-16 20:46 ` Wayne Davison 1999-06-16 21:59 ` history related suggestions (plus bug reports) Wayne Davison 1 sibling, 0 replies; 6+ messages in thread From: Wayne Davison @ 1999-06-16 20:46 UTC (permalink / raw) To: zsh-workers On Wed, 16 Jun 1999, Bart Schaefer wrote: > On a possibly-related note, "history -r" seems to be broken now Yes, the start-of-loop check was wrong. Here's a patch: Index: Src/builtin.c --- zsh-3.1.5-pws-22/Src/builtin.c Mon Jun 14 09:14:30 1999 +++ ./Src/builtin.c Wed Jun 16 13:37:17 1999 @@ -1349,7 +1349,7 @@ fclistdone = 1; ent = gethistent(first, first < last? GETHIST_DOWNWARD : GETHIST_UPWARD); - if (!ent || ent->histnum < first || ent->histnum > last) { + if (!ent || (first < last? ent->histnum > last : ent->histnum < last)) { if (first == last) zwarnnam("fc", "no such event: %d", NULL, first); else ..wayne.. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: history related suggestions (plus bug reports) 1999-06-16 8:19 ` history related suggestions (plus bug reports) Bart Schaefer 1999-06-16 20:46 ` PATCH: pws-22: history -r fix Wayne Davison @ 1999-06-16 21:59 ` Wayne Davison 1999-06-17 6:33 ` Bart Schaefer 1 sibling, 1 reply; 6+ messages in thread From: Wayne Davison @ 1999-06-16 21:59 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers On Wed, 16 Jun 1999, Bart Schaefer wrote: > On Jun 15, 2:10pm, Kiddle, Oliver wrote: > } Subject: history related suggestions > } > } My second suggestion is that the history items imported when zsh first > } runs (if SAVEHIST is set) should be marked as foreign. > > Oh, I don't like that idea at all. Maybe I'm just funny, but a > lot of the time when I start a shell the first thing I do is run a > command searched from the history of my last session. Do you have foreign history toggled off? Or maybe you're thinking that !-history references wouldn't find the old history lines? The line would be visited by default for history movement and searching, though. I haven't yet been convinced that we should go this route, but with some extra changes, this might be a workable solution. One thing that occurred to me was that the infer-next-history function should really find a line in the same local/foreign category as the line we just used, rather than only using local history lines. This would allow the user to execute old sequences of commands that were loaded as foreign, and even new sequences of foreign commands that were loaded via SHARE_HISTORY (though it can get weird if you're reading lines from more than one foreign shell). Also, I have been hesitant to have the default behavior of the history command display the old history lines tagged with '*'s (indicating they are foreign) since I figured that it was less of a compatibility change if this new marking only occurs if you choose to use the SHARE_HISTORY option. However, if others don't think that this would be a bad thing, I could be swayed on the subject. Alternately, we could have the history command only use the new '*'-tagging if SHARE_HISTORY is enabled. > } I'm more likely to recall it than one in my saved history and !1 is > } less typing than !200. Since the history line numbers don't wrap around like you thought, I don't think this is possible. Personally, I find using "!cmd" and the various search commands (especially incremental search backward) easier than using absolute history numbers, but YMMV. > As long as we're on the subject ... the HIST_EXPIRE_DUPS_FIRST > option has some bad side-effects involving the {accept-and,} > infer-next-history zle commands. Yes, that is what I consider an expected consequence: you are specifying a preference for maximizing the number of unique commands rather than maintaining the most recent command sequences. However, the current implementation could be made better with an improvement that I've been meaning to package up for public consumption. Here's the issue: There is a problem with HIST_EXPIRE_DUPS_FIRST where it can become identical to HIST_IGNORE_ALL_DUPS once the internal history fills up with unique commands (at this point, non-unique commands would get immediately dropped). The following patch changes this to limit the size of the unique history commands at the start of the internal history buffer to the $SAVEHIST value. This allows you to set HISTSIZE to a larger number than SAVEHIST, and thus get some slack space for keeping the latest sequences of commands. Index: Src/hist.c --- zsh-3.1.5-pws-22/Src/hist.c Mon Jun 14 09:14:31 1999 +++ ./Src/hist.c Wed Jun 16 14:22:38 1999 @@ -888,9 +888,14 @@ else { he = hist_ring->down; if (isset(HISTEXPIREDUPSFIRST) && !(he->flags & HIST_DUP)) { + int max_unique_ct = getiparam("SAVEHIST"); do { + if (max_unique_ct-- <= 0) { + he = hist_ring->down; + break; + } he = he->down; - } while (he != hist_ring->down && !(he->flags & HIST_DUP)) ; + } while (he != hist_ring->down && !(he->flags & HIST_DUP)); if (he != hist_ring->down) { he->up->down = he->down; he->down->up = he->up; If people like this change, I'll go ahead and document it. While we're on the subject of adversely affecting infer-next-history, it is good to remember that using SHARE_HISTORY also has an adverse effect when a new shell is started (since the shell treats the entire mass of saved history as uniform when it is read in, even when the lines originally came from multiple shells). It would be possible to enhance the history-file format to save the pid of the process that wrote the line, and thus allow us to make history inferences using the next line from the same pid. I'm not sure this is really needed, though (but someone who uses infer-next-history more than me may well disagree). If we add this, I have no idea how to make the history command display which lines are grouped together for recall with infer-next-history. ..wayne.. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: history related suggestions (plus bug reports) 1999-06-16 21:59 ` history related suggestions (plus bug reports) Wayne Davison @ 1999-06-17 6:33 ` Bart Schaefer 0 siblings, 0 replies; 6+ messages in thread From: Bart Schaefer @ 1999-06-17 6:33 UTC (permalink / raw) To: Wayne Davison; +Cc: zsh-workers On Jun 16, 2:59pm, Wayne Davison wrote: } Subject: Re: history related suggestions (plus bug reports) } } On Wed, 16 Jun 1999, Bart Schaefer wrote: } > On Jun 15, 2:10pm, Kiddle, Oliver wrote: } > } Subject: history related suggestions } > } } > } My second suggestion is that the history items imported when zsh first } > } runs (if SAVEHIST is set) should be marked as foreign. } > } > Oh, I don't like that idea at all. Maybe I'm just funny, but a } > lot of the time when I start a shell the first thing I do is run a } > command searched from the history of my last session. } } Do you have foreign history toggled off? Yes. } One thing that occurred to me was that the infer-next-history function } should really find a line in the same local/foreign category as the } line we just used, rather than only using local history lines. I think that would just be confusing. Perhaps better would be if it searched the local or foreign history based on the state of the toggle. However, as you point out: } (though it can get weird if you're reading lines from more than one } foreign shell). } Also, I have been hesitant to have the default behavior of the history } command display the old history lines tagged with '*'s (indicating } they are foreign) since I figured that it was less of a compatibility } change if this new marking only occurs if you choose to use the } SHARE_HISTORY option. I don't see much problem with this, because it's mostly a display thing. (I can't think of any reason, at least not before expire-dups-first came along, to attempt to parse the output of fc or history.) } It would be possible to } enhance the history-file format to save the pid of the process that } wrote the line, and thus allow us to make history inferences using the } next line from the same pid. I'm not sure this is really needed, I think it's probably overkill, and it's also not reliable. Process IDs are hardly unique, especially when NFS gets involved. Maybe I'm being strange yet again, but I prefer predictable mistakes to unpredictable, even if the predictable ones happen a bit more often. } The following patch changes this to limit the size of the unique } history commands at the start of the internal history buffer to the } $SAVEHIST value. This allows you to set HISTSIZE to a larger number } than SAVEHIST, and thus get some slack space for keeping the latest } sequences of commands. Seems fine to me. BTW, before this shared history thing came along, there was never any good reason to make SAVEHSIT bigger than HISTSIZE. Has that changed? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-06-17 7:21 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-06-15 13:10 history related suggestions Kiddle, Oliver 1999-06-15 15:27 ` Peter Stephenson 1999-06-16 8:19 ` history related suggestions (plus bug reports) Bart Schaefer 1999-06-16 20:46 ` PATCH: pws-22: history -r fix Wayne Davison 1999-06-16 21:59 ` history related suggestions (plus bug reports) Wayne Davison 1999-06-17 6:33 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).