Re: up-line-or-search question

Re: up-line-or-search question

[Peter Stephenson]

"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.
**********************************************************************

Re: up-line-or-search question

[Bart Schaefer]

On Wed, 27 Feb 2002, Peter Stephenson wrote:

> Are these the currently agreed definitions?

Yes, those look right to me.

Re: up-line-or-search question

[Oliver Kiddle]

 --- 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

Re: up-line-or-search question

[Peter Stephenson]

=?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.
**********************************************************************

Re: up-line-or-search question

[Bart Schaefer]

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.

Re: up-line-or-search question

[Peter Stephenson]

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.
**********************************************************************

Re: up-line-or-search question

[Oliver Kiddle]

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.

Re: up-line-or-search question

[Bart Schaefer]

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   

Re: up-line-or-search question

[Oliver Kiddle]

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.

Re: up-line-or-search question

[Bart Schaefer]

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

Re: up-line-or-search question

[Oliver Kiddle]

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.

Re: up-line-or-search question

[Bart Schaefer]

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   

Re: up-line-or-search question

[Oliver Kiddle]

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.

Re: up-line-or-search question

[Bart Schaefer]

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.

Re: up-line-or-search question

[Oliver Kiddle]

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.

Re: up-line-or-search question

[Sven Wischnowsky]

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

Re: up-line-or-search question

[Oliver Kiddle]

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.

Re: up-line-or-search question

[Sven Wischnowsky]

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

Re: up-line-or-search question

[Sven Wischnowsky]

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