* Re: up-line-or-search question [not found] <1020227161622.ZM10705@candle.brasslantern.com> @ 2002-02-27 16:29 ` Peter Stephenson 2002-02-27 16:56 ` Bart Schaefer ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Peter Stephenson @ 2002-02-27 16:29 UTC (permalink / raw) To: Zsh hackers list "Bart Schaefer" wrote: > Search the zsh-users archive for the string: up-line-or-beginning Are these the currently agreed definitions? If so, they can be added to Functions/Zle and the zshcontrib manual page. function up-line-or-beginning-search { if [[ $LASTWIDGET != $WIDGET ]] then if [[ $LBUFFER == *$'\n'* ]] then __last_up_line=up-line-or-history else __last_up_line=history-beginning-search-backward fi fi zle .${__last_up_line:-beep} } function down-line-or-beginning-search { if [[ $LASTWIDGET != $WIDGET ]] then if [[ $LBUFFER == *$'\n'* ]] then __last_down_line=down-line-or-history else __last_down_line=history-beginning-search-forward fi fi zle .${__last_down_line:-beep} } -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-02-27 16:29 ` up-line-or-search question Peter Stephenson @ 2002-02-27 16:56 ` Bart Schaefer 2002-02-27 17:07 ` Oliver Kiddle 2002-03-21 22:56 ` Peter Stephenson 2 siblings, 0 replies; 19+ messages in thread From: Bart Schaefer @ 2002-02-27 16:56 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh hackers list On Wed, 27 Feb 2002, Peter Stephenson wrote: > Are these the currently agreed definitions? Yes, those look right to me. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-02-27 16:29 ` up-line-or-search question Peter Stephenson 2002-02-27 16:56 ` Bart Schaefer @ 2002-02-27 17:07 ` Oliver Kiddle 2002-02-27 17:29 ` Peter Stephenson 2002-03-21 22:56 ` Peter Stephenson 2 siblings, 1 reply; 19+ messages in thread From: Oliver Kiddle @ 2002-02-27 17:07 UTC (permalink / raw) To: zsh-workers --- Peter Stephenson <pws@csr.com> wrote: > "Bart Schaefer" wrote: > > Search the zsh-users archive for the string: up-line-or-beginning > > Are these the currently agreed definitions? If so, they can be added > to Functions/Zle and the zshcontrib manual page. Those look like what Bart suggested but they aren't what I now use. If I remember correctly, opinions varied as to what should happen on the first line of a multi-line buffer. I'm also still undecided about the cursor positioning and considered having the function move it to the end of the line or even to where it was when I pressed enter (for the last command only). If, I remember rightly, someone else on -users also ended up with some other variation. Am I the only one on -workers who uses something like this? I could put together what I think is best and stick it in Functions/Zle (next week when I might have some time)? Or we could write a style configurable one? Another option would be to think about my past point that it would be easier to write these things if the builtin widgets were more primitive. I don't suppose writing basic up-line and down-lines is going to be hard. Oliver __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-02-27 17:07 ` Oliver Kiddle @ 2002-02-27 17:29 ` Peter Stephenson 2002-02-27 18:03 ` Bart Schaefer 0 siblings, 1 reply; 19+ messages in thread From: Peter Stephenson @ 2002-02-27 17:29 UTC (permalink / raw) To: Zsh hackers list =?iso-8859-1?q?Oliver=20Kiddle?= wrote: > Those look like what Bart suggested but they aren't what I now use. Well, it doesn't matter which we add for the time being, but we should stick in one or other for people to try out. Probably it can safely go in 4.0 as well. The answer to the question Bart asked the first time round `how do I find out if I'm at PS2' is, unless I'm missing a subtlety, `[[ -n $PREBUFFER ]]'. It's not clear to me what you do in that case anyway. -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-02-27 17:29 ` Peter Stephenson @ 2002-02-27 18:03 ` Bart Schaefer 0 siblings, 0 replies; 19+ messages in thread From: Bart Schaefer @ 2002-02-27 18:03 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh hackers list On Wed, 27 Feb 2002, Peter Stephenson wrote: > The answer to the question Bart asked the first time round `how do I > find out if I'm at PS2' is, unless I'm missing a subtlety, `[[ -n > $PREBUFFER ]]'. (Hand smacks forehead) > It's not clear to me what you do in that case anyway. My knee-jerk reaction was to say "never do history-beginning-search" but on further though I can see why it might sometimes be wanted. Personally, I'd do something like [[ -n $PREBUFFER ]] && zle .push-line-or-edit which would be perfect if only it didn't beep. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-02-27 16:29 ` up-line-or-search question Peter Stephenson 2002-02-27 16:56 ` Bart Schaefer 2002-02-27 17:07 ` Oliver Kiddle @ 2002-03-21 22:56 ` Peter Stephenson 2002-03-26 14:30 ` Oliver Kiddle 2 siblings, 1 reply; 19+ messages in thread From: Peter Stephenson @ 2002-03-21 22:56 UTC (permalink / raw) To: Zsh hackers list Peter Stephenson wrote: > "Bart Schaefer" wrote: > > Search the zsh-users archive for the string: up-line-or-beginning > > Are these the currently agreed definitions? If so, they can be added to > Functions/Zle and the zshcontrib manual page. I'm going to commit the following. It's up to Oliver whether he wants to do something more sophisticated. Index: Doc/Zsh/contrib.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/contrib.yo,v retrieving revision 1.18 diff -u -r1.18 contrib.yo --- Doc/Zsh/contrib.yo 5 Mar 2002 16:33:21 -0000 1.18 +++ Doc/Zsh/contrib.yo 21 Mar 2002 22:55:06 -0000 @@ -430,6 +430,17 @@ bindkey '\e^P' history-beginning-search-backward-end bindkey '\e^N' history-beginning-search-forward-end) ) +tindex(up-line-or-beginning-search) +tindex(down-line-or-beginning-search) +item(tt(up-line-or-beginning-search), tt(down-line-or-beginning-search))( +These widgets are similar to the builtin functions tt(up-line-or-search) +and tt(down-line-or-search): if in a multiline buffer they move up or +down within the buffer, otherwise they search for a history line matching +the start of the current line. In this case, however, they search for +a line which matches the current line up to the current cursor position, in +the manner of tt(history-begining-search-backward) and tt(-forward), rather +than the first word on the line. +) tindex(incarg) vindex(incarg, use of) item(tt(incarg))( Index: Functions/Zle/down-line-or-beginning-search =================================================================== RCS file: Functions/Zle/down-line-or-beginning-search diff -N Functions/Zle/down-line-or-beginning-search --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ Functions/Zle/down-line-or-beginning-search 21 Mar 2002 22:55:06 -0000 @@ -0,0 +1,13 @@ +# Like down-line-or-search, but uses the whole line prefix up to the +# cursor position for searching forwards. + +if [[ $LASTWIDGET != $WIDGET ]] +then + if [[ $LBUFFER == *$'\n'* ]] + then + __last_down_line=down-line-or-history + else + __last_down_line=history-beginning-search-forward + fi +fi +zle .${__last_down_line:-beep} Index: Functions/Zle/up-line-or-beginning-search =================================================================== RCS file: Functions/Zle/up-line-or-beginning-search diff -N Functions/Zle/up-line-or-beginning-search --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ Functions/Zle/up-line-or-beginning-search 21 Mar 2002 22:55:06 -0000 @@ -0,0 +1,13 @@ +# Like up-line-or-search, but uses the whole line prefix up to the +# cursor position for searching backwards. + +if [[ $LASTWIDGET != $WIDGET ]] +then + if [[ $LBUFFER == *$'\n'* ]] + then + __last_up_line=up-line-or-history + else + __last_up_line=history-beginning-search-backward + fi +fi +zle .${__last_up_line:-beep} -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ********************************************************************** ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-03-21 22:56 ` Peter Stephenson @ 2002-03-26 14:30 ` Oliver Kiddle 2002-03-26 15:48 ` Bart Schaefer 0 siblings, 1 reply; 19+ messages in thread From: Oliver Kiddle @ 2002-03-26 14:30 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh hackers list On Thu, Mar 21, 2002 at 10:56:31PM +0000, Peter Stephenson wrote: > I'm going to commit the following. It's up to Oliver whether he wants > to do something more sophisticated. Sorry, I had forgotten about this. I think the best to use is perhaps Martin Ebourne's from 16011. It is as follows though I've modified it slightly so that it will do a down line if we are back at the end of the history and so that you can force a down history with a numeric argument. Does anyone think it is worth it to incorporate Dominik Vogt's changes in users/4712 which basically just account for lines containing only spaces and tabs? In the function I use, I also have: elif [[ -n $PREBUFFER ]]; then zle .push-line-or-edit in the middle of the up-line function (unfortuately adding an up-line-or-history after push-line-or-edit doesn't seem to work). I expect most users wouldn't expect this so I'll leave it out. I was also hoping to move the cursor to the end of the line after searches but I can't see how I can move it back before the next search without using the mark. I was hoping someone else would answer the question in users/4735 because I don't know the answer myself and suspect it can't be done. So, are there any objections if I commit the following instead? Peter's documentation looks to still be entirely applicable. Oliver up-line-or-beginning-search() { if [[ $LBUFFER == *$'\n'* ]]; then zle .up-line-or-history __searching='' else zle .history-beginning-search-backward __searching=$WIDGET fi } down-line-or-beginning-search() { if [[ $LASTWIDGET = $__searching || $NUMERIC -gt 0 ]] && zle .history-beginning-search-forward; then __searching=$WIDGET elif [[ $RBUFFER == *$'\n'* ]]; then __searching='' zle .down-line-or-history else __searching=$WIDGET zle .history-beginning-search-forward fi } This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-03-26 14:30 ` Oliver Kiddle @ 2002-03-26 15:48 ` Bart Schaefer 2002-03-26 19:23 ` Oliver Kiddle 0 siblings, 1 reply; 19+ messages in thread From: Bart Schaefer @ 2002-03-26 15:48 UTC (permalink / raw) To: Oliver Kiddle; +Cc: Zsh hackers list On Mar 26, 2:30pm, Oliver Kiddle wrote: } Subject: Re: up-line-or-search question } } I think the best to use is perhaps Martin Ebourne's from 16011. It is } as follows though I've modified it slightly so that it will do a down } line if we are back at the end of the history and so that you can force } a down history with a numeric argument. You mean this code: } if [[ $LASTWIDGET = $__searching || $NUMERIC -gt 0 ]] && } zle .history-beginning-search-forward; then } __searching=$WIDGET That doesn't look quite right to me. If history-beginning-search-forward fails, it may get tried *again* by the final "else" clause. And that's forcing a search with a numeric argument, not a down history? Seems like it should be down-line-or-beginning-search() { if [[ ${+NUMERIC} -eq 0 && ( $LASTWIDGET = $__searching || $RBUFFER != *$'\n'* ) ]] then __searching=$WIDGET zle .history-beginning-search-forward else __searching='' zle .down-line-or-history fi } } Does anyone think it is worth it to incorporate Dominik Vogt's changes } in users/4712 which basically just account for lines containing only } spaces and tabs? There's nothing wrong with them, but I probably wouldn't. } In the function I use, I also have: } } elif [[ -n $PREBUFFER ]]; then } zle .push-line-or-edit } } in the middle of the up-line function (unfortuately adding an } up-line-or-history after push-line-or-edit doesn't seem to work). Yes, I have that too. As I've mentioned before, push-line-or-edit has to do a trashzle() internally to force the redraw without the PS2 prompt, and that has the side-effect of aborting everything that the editor is doing, so the function can't continue after calling it. I wish there were a better way. } I was also hoping to move the cursor to the end of the line after } searches but I can't see how I can move it back before the next search } without using the mark. Stash the value of CURSOR in another global, __searching_pos or some such, and re-assign to CURSOR only when [[ -n $__searching ]]. } I was hoping someone else would answer the question in users/4735 } because I don't know the answer myself and suspect it can't be done. Sure it can; I missed 4735 somehow. You just append the arguments to the `zle' command after the name of the widget. In the case of the specific question in 4735, it's the numeric argument, so you have to use -n, e.g.: zle .vi-fetch-history -n $NUMERIC I forget whether the default is to propagate $NUMERIC (i.e. if the above is redundant and you only need -n to change the value). -- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-03-26 15:48 ` Bart Schaefer @ 2002-03-26 19:23 ` Oliver Kiddle 2002-03-26 19:51 ` Bart Schaefer 0 siblings, 1 reply; 19+ messages in thread From: Oliver Kiddle @ 2002-03-26 19:23 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh hackers list On Tue, Mar 26, 2002 at 03:48:50PM +0000, Bart Schaefer wrote: > That doesn't look quite right to me. If history-beginning-search-forward > fails, it may get tried *again* by the final "else" clause. And that's > forcing a search with a numeric argument, not a down history? > > Seems like it should be I didn't realise that the numeric argument would propagate so thought the second history-beginning-search-backward was harmless. Your replacement breaks the addition that it goes down a line if at the end of the history. So, I think it should be: down-line-or-beginning-search() { if [[ ${+NUMERIC} -eq 0 && ( $LASTWIDGET = $__searching || $RBUFFER != *$'\n'* ) ]] then __searching=$WIDGET zle .history-beginning-search-forward && return fi __searching='' zle .down-line-or-history } > } I was also hoping to move the cursor to the end of the line after > } searches but I can't see how I can move it back before the next search > } without using the mark. > > Stash the value of CURSOR in another global, __searching_pos or some > such, and re-assign to CURSOR only when [[ -n $__searching ]]. I got confused by the documentation stating that those variables are read-only and forgot about assigning to CURSOR, thanks. Changing the zle h-b-s-? commands to: [[ $LASTWIDGET = $__searching ]] && CURSOR=$__savecursor zle .history-beginning-search-backward __savecursor=$CURSOR zle .end-of-line (and moving the return statement in the down-line function) It works for going up but breaks when changing to going down. Basically, it searches down using the whole line instead of up to where the cursor was. Any ideas? > Sure it can; I missed 4735 somehow. You just append the arguments to > the `zle' command after the name of the widget. In the case of the > specific question in 4735, it's the numeric argument, so you have to > use -n, e.g.: > > zle .vi-fetch-history -n $NUMERIC > > I forget whether the default is to propagate $NUMERIC (i.e. if the above > is redundant and you only need -n to change the value). Ok. Thanks. It isn't possible to include args (numeric or otherwise) with a bindkey though is it? Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-03-26 19:23 ` Oliver Kiddle @ 2002-03-26 19:51 ` Bart Schaefer 2002-03-27 12:59 ` Oliver Kiddle 0 siblings, 1 reply; 19+ messages in thread From: Bart Schaefer @ 2002-03-26 19:51 UTC (permalink / raw) To: Oliver Kiddle; +Cc: Zsh hackers list On Tue, 26 Mar 2002, Oliver Kiddle wrote: > I didn't realise that the numeric argument would propagate so thought > the second history-beginning-search-backward was harmless. Your > replacement breaks the addition that it goes down a line if at the end > of the history. I'd rather have it feep at the end of the history. Moving down a line when the search fails means I lose my context and have to re-establish it before I can e.g. reverse the direction of the search. > Changing the zle h-b-s-? commands to: > > [[ $LASTWIDGET = $__searching ]] && CURSOR=$__savecursor > zle .history-beginning-search-backward > __savecursor=$CURSOR > zle .end-of-line > (and moving the return statement in the down-line function) > > It works for going up but breaks when changing to going down. > Basically, it searches down using the whole line instead of up to where > the cursor was. Any ideas? Don't test [[ $LASTWIDGET = $__searching ]], test [[ -n $__searching ]]. And name the cursor-saving variable something less generic, there may be other functions that want to save and restore the cursor ... > > zle .vi-fetch-history -n $NUMERIC > > Ok. Thanks. It isn't possible to include args (numeric or otherwise) > with a bindkey though is it? I'm not sure what you mean. If you mean supply args at the time that you invoke the key binding, then you only get the numeric argument (digits typed as a prefix, in vi mode). If you mean supply args at the time you create the key binding, then you just create a new widget that has the arguments and call it: function vi-fetch-history-twentyseven { zle .vi-fetch-history -n 27 # Always retrieve event 27 } zle -N vi-fetch-history-twentyseven bindkey -v g vi-fetch-history-twentyseven ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-03-26 19:51 ` Bart Schaefer @ 2002-03-27 12:59 ` Oliver Kiddle 2002-03-27 16:30 ` Bart Schaefer 0 siblings, 1 reply; 19+ messages in thread From: Oliver Kiddle @ 2002-03-27 12:59 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers On Tue, Mar 26, 2002 at 11:51:01AM -0800, Bart Schaefer wrote: > > I'd rather have it feep at the end of the history. Moving down a line > when the search fails means I lose my context and have to re-establish > it before I can e.g. reverse the direction of the search. In the case of this function, re-establishing the context is merely a case of pressing the up cursor which I don't think is that much of a problem. I did get it slightly wrong in the last function though because if the h-b-s-f fails and the subsequent d-l-o-h does a down history instead of down line, it is not good. So it needs: [[ $RBUFFER = *$'\n'* ]] || return before the fi. > Don't test [[ $LASTWIDGET = $__searching ]], test [[ -n $__searching ]]. > And name the cursor-saving variable something less generic, there may be > other functions that want to save and restore the cursor ... That doesn't help. It also means that the cursor position for searches is then fixed forever after for that shell instance. I think I've got it working now but am not sure why or whether there was something peculiar with the history list I had yesterday. Do we want to include the cursor movement in the examples in the distribution - it is more like up-line-or- search? Perhaps we need to use styles to configure it? > I'm not sure what you mean. If you mean supply args at the time that you I meant at the time when the key binding is created. That answers my question, thanks. Oliver -- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-03-27 12:59 ` Oliver Kiddle @ 2002-03-27 16:30 ` Bart Schaefer 2002-03-27 18:00 ` Oliver Kiddle 0 siblings, 1 reply; 19+ messages in thread From: Bart Schaefer @ 2002-03-27 16:30 UTC (permalink / raw) To: Oliver Kiddle; +Cc: zsh-workers On Mar 27, 12:59pm, Oliver Kiddle wrote: } Subject: Re: up-line-or-search question } } On Tue, Mar 26, 2002 at 11:51:01AM -0800, Bart Schaefer wrote: } > } > I'd rather have it feep at the end of the history. Moving down a line } > when the search fails means I lose my context and have to re-establish } > it before I can e.g. reverse the direction of the search. } } In the case of this function, re-establishing the context is } merely a case of pressing the up cursor which I don't think is } that much of a problem. The problem I was concerned about was this one: } I did get it slightly wrong in the last function though } because if the h-b-s-f fails and the subsequent d-l-o-h does a } down history instead of down line, it is not good. So it } needs: } [[ $RBUFFER = *$'\n'* ]] || return } before the fi. So if you've made that change, it shoudl be OK. } > Don't test [[ $LASTWIDGET = $__searching ]], test [[ -n $__searching ]]. } > And name the cursor-saving variable something less generic, there may be } > other functions that want to save and restore the cursor ... } } That doesn't help. It also means that the cursor position for } searches is then fixed forever after for that shell instance. Not exactly -- __searching will get cleared as soon as a search fails and a simple up/down motion is done -- but you're right, the test should be [[ $__searching = *-line-or-search && $LASTWIDGET = *-line-or-search ]] or something along those lines. Incidentally, a (possibly better) alternative to saving $CURSOR is to save $LBUFFER and use it: if [[ ... ]]; then __last_search=$LBUFFER fi zle .history-beginning-search-forward $__last_search } I think I've got it working now but am not sure why or whether } there was something peculiar with the history list I had } yesterday. Do we want to include the cursor movement in } the examples in the distribution - it is more like up-line-or- } search? Perhaps we need to use styles to configure it? Styles are always nice; I'd be inclined to put the cursor movement in and have a style to turn it off. -- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-03-27 16:30 ` Bart Schaefer @ 2002-03-27 18:00 ` Oliver Kiddle 2002-03-27 18:19 ` Bart Schaefer 0 siblings, 1 reply; 19+ messages in thread From: Oliver Kiddle @ 2002-03-27 18:00 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers On Wed, Mar 27, 2002 at 04:30:03PM +0000, Bart Schaefer wrote: > > Not exactly -- __searching will get cleared as soon as a search fails and > a simple up/down motion is done -- but you're right, the test should be > [[ $__searching = *-line-or-search && $LASTWIDGET = *-line-or-search ]] > or something along those lines. I'm not quite sure what that is trying to achieve. I also can't remember how I got it not to work in the first place because it is now. > Incidentally, a (possibly better) alternative to saving $CURSOR is to > save $LBUFFER and use it: > > if [[ ... ]]; then > __last_search=$LBUFFER > fi > zle .history-beginning-search-forward $__last_search Interesting. If I was just planning to put the cursor at the end of the line in all cases, it would probably be better. It is useful to think about though because it would allow the resumption of the search with the same string even if the line had been edited. > } yesterday. Do we want to include the cursor movement in > } the examples in the distribution - it is more like up-line-or- > } search? Perhaps we need to use styles to configure it? > > Styles are always nice; I'd be inclined to put the cursor movement in > and have a style to turn it off. Okay, I'll probably put the push-line-or-edit in when enabled with a style too then. Could we maybe agree a common prefix for the contexts of the styles in Functions/Zle - ':zle:' maybe? It is probably best to stick with zle .end-of-line in whatever goes in Functions/Zle but I'm not sure that it is exactly what I want to happen for the cursor position. I'm currently experimenting with this: if (( HISTNO + 1 == ${(%%):-%h} )) && [[ $BUFFER[1,__savepos] != *$'\n'* ]] then CURSOR=__savepos elif [[ $RBUFFER != *$'\n'* ]]; then zle .end-of-line fi as the cursor positioning and using: accept-line-and-savepos() { __savepos=$CURSOR zle .accept-line } instead of accept-line (I probably also need to do others like accept-line-and-down-history). On the way down, I'm not moving the cursor at all. It's one of those things where I need to use it for a while before I decide if it is a good idea or not but let me know if you see any problems or if this sparks off any other ideas. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-03-27 18:00 ` Oliver Kiddle @ 2002-03-27 18:19 ` Bart Schaefer 2002-03-27 19:35 ` Oliver Kiddle 0 siblings, 1 reply; 19+ messages in thread From: Bart Schaefer @ 2002-03-27 18:19 UTC (permalink / raw) To: Oliver Kiddle; +Cc: zsh-workers On Wed, 27 Mar 2002, Oliver Kiddle wrote: > On Wed, Mar 27, 2002 at 04:30:03PM +0000, Bart Schaefer wrote: > > > > Not exactly -- __searching will get cleared as soon as a search fails and > > a simple up/down motion is done -- but you're right, the test should be > > [[ $__searching = *-line-or-search && $LASTWIDGET = *-line-or-search ]] > > or something along those lines. > > I'm not quite sure what that is trying to achieve. It's just treating searches in both directions as equivalent for purposes of whether to re-use the saved cursor position (or string) or to start a new search with the current $LBUFFER. > I also can't remember how I got it not to work in the first place > because it is now. Search up successfully, and then immediately try to search down again? > Okay, I'll probably put the push-line-or-edit in when enabled with > a style too then. Could we maybe agree a common prefix for the > contexts of the styles in Functions/Zle - ':zle:' maybe? E.g., change :predict to :zle:predict ? I wish we'd thought about that sooner ... it's not a bad idea, but it means changing predict-on, incremental-complete-word, etc. ... maybe we can use the excuse of differentiating complex stateful widgets from simple zle functions. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-03-27 18:19 ` Bart Schaefer @ 2002-03-27 19:35 ` Oliver Kiddle 2002-03-28 10:01 ` Sven Wischnowsky 0 siblings, 1 reply; 19+ messages in thread From: Oliver Kiddle @ 2002-03-27 19:35 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers On Wed, Mar 27, 2002 at 10:19:23AM -0800, Bart Schaefer wrote: > > Search up successfully, and then immediately try to search down again? That now works. I probably had something messed up yesterday. > E.g., change :predict to :zle:predict ? Exactly. > I wish we'd thought about that sooner ... it's not a bad idea, but it > means changing predict-on, incremental-complete-word, etc. ... maybe > we can use the excuse of differentiating complex stateful widgets from > simple zle functions. I would be inclined to change them anyway but if it worries you, we could use something like: zstyle -t :zle:predict verbose || zle -t :predict verbose I've put the functions below in a recent form but without some of my weirder additions. Suggestions on suitable shortenings for the style contexts welcome. Or any other changes? I've also added another bit to the up-line function which causes it to still do an up-history if the search failed but we are not currently in a search. This allows it to still be clear when a search reaches it's end but it will still go up when searching isn't going to do anything. Any views on this? Perhaps it also needs a style. Note that a corresponding change to the down function would be needed. Oliver up-line-or-beginning-search() { [[ $LASTWIDGET != $__searching ]] local insearch=$? if [[ $LBUFFER == *$'\n'* ]]; then zle .up-line-or-history __searching='' elif [[ -n $PREBUFFER ]] && zstyle -t ':zle:up-line-or-beginning-search' edit-buffer then zle .push-line-or-edit else (( insearch )) && CURSOR=$__savecursor __savecursor=$CURSOR __searching=$WIDGET if ! zle .history-beginning-search-backward && (( ! insearch )); then zle .up-history CURSOR=0 fi zstyle -T ':zle:up-line-or-beginning-search' leave-cursor && zle .end-of-line fi } down-line-or-beginning-search() { if [[ ${+NUMERIC} -eq 0 && ( $LASTWIDGET = $__searching || $RBUFFER != *$'\n'* ) ]] then [[ $LASTWIDGET = $__searching ]] && CURSOR=$__savecursor __searching=$WIDGET __savecursor=$CURSOR if zle .history-beginning-search-forward; then [[ $RBUFFER = *$'\n'* ]] || zstyle -T ':zle:down-line-or-beginning-search' leave-cursor && zle .end-of-line return fi [[ $RBUFFER = *$'\n'* ]] || return fi __searching='' zle .down-line-or-history } This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-03-27 19:35 ` Oliver Kiddle @ 2002-03-28 10:01 ` Sven Wischnowsky 2002-04-04 11:46 ` Oliver Kiddle 0 siblings, 1 reply; 19+ messages in thread From: Sven Wischnowsky @ 2002-03-28 10:01 UTC (permalink / raw) To: zsh-workers Oliver Kiddle wrote: > ... > > I would be inclined to change them anyway but if it worries you, we could > use something like: > > zstyle -t :zle:predict verbose || zle -t :predict verbose > > I've put the functions below in a recent form but without some of my > weirder additions. Suggestions on suitable shortenings for the style > contexts welcome. Or any other changes? I don't really like this double testing and personally would vote to put everything under the :zle top-level context. I'd like to know how many users are out there who have styles for any of the (currently only three) zle functions. Maybe we should ask on zsh-users? But first we should probably try to come up with a context format like the one we have for the completion system, with a fixed number of parts (some of which may be blank most of the time), which allows us to extend it to future uses. And that's hard to predict, I fear. Maybe we will eventually have a way to get the context-information- gathering-part of the completion system from normal zle widgets. I had collected some ideas for that (and the suffix stuff etc.) but on saturday my hard disk was killed. Sigh. Bye Sven -- Sven Wischnowsky wischnow@berkom.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-03-28 10:01 ` Sven Wischnowsky @ 2002-04-04 11:46 ` Oliver Kiddle 2002-04-09 9:51 ` Sven Wischnowsky 2002-04-16 7:47 ` Sven Wischnowsky 0 siblings, 2 replies; 19+ messages in thread From: Oliver Kiddle @ 2002-04-04 11:46 UTC (permalink / raw) To: Sven Wischnowsky; +Cc: zsh-workers On Thu, Mar 28, 2002 at 11:01:33AM +0100, Sven Wischnowsky wrote: > > I don't really like this double testing and personally would vote to > put everything under the :zle top-level context. I'd like to know how > many users are out there who have styles for any of the (currently > only three) zle functions. Maybe we should ask on zsh-users? I think I'd also vote for just changing it. > But first we should probably try to come up with a context format like > the one we have for the completion system, with a fixed number of > parts (some of which may be blank most of the time), which allows us > to extend it to future uses. And that's hard to predict, I fear. What else might we want in the context? Most of the things used for completion wouldn't make sense because we don't dispatch based on such things as the command and we don't have any tags. The full name of the widget function is certainly useful (abbreviating it is perhaps unwise). What else? The key combination used is the only other thing I can think of. > I had collected some ideas for that (and the suffix stuff etc.) but on > saturday my hard disk was killed. Sigh. Oh dear. On the subject of suffix stuff, I recently had problems with a completion widget which did compset -P '*,' and then a compadd -Q -U -qS, If the comma taken off by compset was added as an autoremovable suffix earlier then it gets removed when the next part is inserted. I can send you the functions if you don't understand. Patch below is those up/down search widgets in the form that I'll commit for now before I lose them. Oliver Index: Functions/Zle/down-line-or-beginning-search =================================================================== RCS file: /cvsroot/zsh/zsh/Functions/Zle/down-line-or-beginning-search,v retrieving revision 1.1 diff -u -r1.1 down-line-or-beginning-search --- Functions/Zle/down-line-or-beginning-search 21 Mar 2002 23:03:14 -0000 1.1 +++ Functions/Zle/down-line-or-beginning-search 4 Apr 2002 11:15:51 -0000 @@ -1,13 +1,19 @@ # Like down-line-or-search, but uses the whole line prefix up to the # cursor position for searching forwards. -if [[ $LASTWIDGET != $WIDGET ]] +if [[ ${+NUMERIC} -eq 0 && + ( $LASTWIDGET = $__searching || $RBUFFER != *$'\n'* ) ]] then - if [[ $LBUFFER == *$'\n'* ]] - then - __last_down_line=down-line-or-history - else - __last_down_line=history-beginning-search-forward - fi + [[ $LASTWIDGET = $__searching ]] && CURSOR=$__savecursor + __searching=$WIDGET + __savecursor=$CURSOR + if zle .history-beginning-search-forward; then + [[ $RBUFFER = *$'\n'* ]] || + zstyle -T ':zle:down-line-or-beginning-search' leave-cursor && + zle .end-of-line + return + fi + [[ $RBUFFER = *$'\n'* ]] || return fi -zle .${__last_down_line:-beep} +__searching='' +zle .down-line-or-history Index: Functions/Zle/up-line-or-beginning-search =================================================================== RCS file: /cvsroot/zsh/zsh/Functions/Zle/up-line-or-beginning-search,v retrieving revision 1.1 diff -u -r1.1 up-line-or-beginning-search --- Functions/Zle/up-line-or-beginning-search 21 Mar 2002 23:03:14 -0000 1.1 +++ Functions/Zle/up-line-or-beginning-search 4 Apr 2002 11:15:51 -0000 @@ -1,13 +1,18 @@ # Like up-line-or-search, but uses the whole line prefix up to the # cursor position for searching backwards. -if [[ $LASTWIDGET != $WIDGET ]] +if [[ $LBUFFER == *$'\n'* ]]; then + zle .up-line-or-history + __searching='' +elif [[ -n $PREBUFFER ]] && + zstyle -t ':zle:up-line-or-beginning-search' edit-buffer then - if [[ $LBUFFER == *$'\n'* ]] - then - __last_up_line=up-line-or-history - else - __last_up_line=history-beginning-search-backward - fi + zle .push-line-or-edit +else + [[ $LASTWIDGET = $__searching ]] && CURSOR=$__savecursor + __savecursor=$CURSOR + __searching=$WIDGET + zle .history-beginning-search-backward + zstyle -T ':zle:up-line-or-beginning-search' leave-cursor && + zle .end-of-line fi -zle .${__last_up_line:-beep} This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-04-04 11:46 ` Oliver Kiddle @ 2002-04-09 9:51 ` Sven Wischnowsky 2002-04-16 7:47 ` Sven Wischnowsky 1 sibling, 0 replies; 19+ messages in thread From: Sven Wischnowsky @ 2002-04-09 9:51 UTC (permalink / raw) To: zsh-workers Oliver Kiddle wrote: > ... > > > But first we should probably try to come up with a context format like > > the one we have for the completion system, with a fixed number of > > parts (some of which may be blank most of the time), which allows us > > to extend it to future uses. And that's hard to predict, I fear. > > What else might we want in the context? Most of the things used for > completion wouldn't make sense because we don't dispatch based on > such things as the command and we don't have any tags. The full name > of the widget function is certainly useful (abbreviating it is perhaps > unwise). What else? The key combination used is the only other thing I > can think of. Unless we ever come around to implementing a way to get the context-information from the completion code in normal widgets (we had this discussion some time ago, for a word-movement widget). Bye Sven -- Sven Wischnowsky wischnow@berkom.de ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: up-line-or-search question 2002-04-04 11:46 ` Oliver Kiddle 2002-04-09 9:51 ` Sven Wischnowsky @ 2002-04-16 7:47 ` Sven Wischnowsky 1 sibling, 0 replies; 19+ messages in thread From: Sven Wischnowsky @ 2002-04-16 7:47 UTC (permalink / raw) To: zsh-workers Oliver Kiddle wrote: > ... > > On the subject of suffix stuff, I recently had problems with > a completion widget which did compset -P '*,' and then a compadd -Q -U -qS, > If the comma taken off by compset was added as an autoremovable suffix > earlier then it gets removed when the next part is inserted. I can send > you the functions if you don't understand. Hm, yes, I need the function. I tried it but obviously I was really trying something different than you did, because it worked. Bye Sven -- Sven Wischnowsky wischnow@berkom.de ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2002-04-16 7:48 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1020227161622.ZM10705@candle.brasslantern.com> 2002-02-27 16:29 ` up-line-or-search question Peter Stephenson 2002-02-27 16:56 ` Bart Schaefer 2002-02-27 17:07 ` Oliver Kiddle 2002-02-27 17:29 ` Peter Stephenson 2002-02-27 18:03 ` Bart Schaefer 2002-03-21 22:56 ` Peter Stephenson 2002-03-26 14:30 ` Oliver Kiddle 2002-03-26 15:48 ` Bart Schaefer 2002-03-26 19:23 ` Oliver Kiddle 2002-03-26 19:51 ` Bart Schaefer 2002-03-27 12:59 ` Oliver Kiddle 2002-03-27 16:30 ` Bart Schaefer 2002-03-27 18:00 ` Oliver Kiddle 2002-03-27 18:19 ` Bart Schaefer 2002-03-27 19:35 ` Oliver Kiddle 2002-03-28 10:01 ` Sven Wischnowsky 2002-04-04 11:46 ` Oliver Kiddle 2002-04-09 9:51 ` Sven Wischnowsky 2002-04-16 7:47 ` Sven Wischnowsky
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).