Re: Preventing sorting in completers

Re: Preventing sorting in completers

[Bart Schaefer]

On Jul 12,  7:49pm, Philippe Troin wrote:
} 
} zstyle ":completion:*:processes" command \
}   'ps -u $UID -o ''pid tty s args'' --forest'

Hmm.  When I try to use that set of "ps" arguments, I get no completions
at all.  Some investigation reveals that "ps" is giving

ERROR: TTY could not be found.

However, assuming that it's working for you ...

} The problem is that the completion frameworks show the process list
} sorted by PID. How can I prevent that and get the process list in the
} order it was returned by ps (so that --forest makes sense).

You need to edit the _pids function and change the line

 _wanted processes expl 'process ID' compadd "$@" "$desc[@]" "$all[@]" -a pids && ret=0

To

 _wanted -V processes expl 'process ID' compadd "$@" "$desc[@]" "$all[@]" -a pids && ret=0

Bonus points for making use of the "sort" style and submitting a patch ...

Re: Preventing sorting in completers

[Peter Stephenson]

Bart Schaefer wrote:
> On Jul 12,  7:49pm, Philippe Troin wrote:
> } 
> } zstyle ":completion:*:processes" command \
> }   'ps -u $UID -o ''pid tty s args'' --forest'
> 
> Hmm.  When I try to use that set of "ps" arguments, I get no completions
> at all.  Some investigation reveals that "ps" is giving
> 
> ERROR: TTY could not be found.

My guess is your system is using stdout to decide what the tty is, which
is explicitly closed.  Try using 1>&2 on the ps command line.  (Or
something gets closed.  Is it stdin?  Anyway, reopen it.)

> You need to edit the _pids function and change the line
> 
>  _wanted processes expl 'process ID' compadd "$@" "$desc[@]" "$all[@]" -a pid
> s && ret=0
> 
> To
> 
>  _wanted -V processes expl 'process ID' compadd "$@" "$desc[@]" "$all[@]" -a 
> pids && ret=0
> 
> Bonus points for making use of the "sort" style and submitting a patch ...

This -J/-V business always got me really confused.  The documentation
for _wanted says it takes the same arguments as _requested.  _requested
doesn't say anything about its arguments, but _description, which is
down there underneath, does say how it handles them.  Passing them down
is a bit of a nightmare.

I suspect what we want to do is test for an explicitly set sort style in
_description and used that to override the default.  Then we can all
forget about tweaking the functions.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
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: Preventing sorting in completers

[Danek Duvall]

Peter Stephenson wrote:

> Bart Schaefer wrote:
> > On Jul 12,  7:49pm, Philippe Troin wrote:
> > } 
> > } zstyle ":completion:*:processes" command \
> > }   'ps -u $UID -o ''pid tty s args'' --forest'
> > 
> > Hmm.  When I try to use that set of "ps" arguments, I get no completions
> > at all.  Some investigation reveals that "ps" is giving
> > 
> > ERROR: TTY could not be found.
> 
> My guess is your system is using stdout to decide what the tty is, which
> is explicitly closed.  Try using 1>&2 on the ps command line.  (Or
> something gets closed.  Is it stdin?  Anyway, reopen it.)

I just looked at this, and I get the same error just by running

    ps -o pid tty s args

which is effectively what's getting run above.  I believe that -o
requires *one* argument, with either space or comma separated fields:

    ps -o 'pid tty s args'

or

    ps -o pid,tty,s,args

both of which succeed, and print out a perfectly decent process listing.

I would guess that the double single quotes that Philippe is using
should probably be single quotes escaped by backslashes, or double
quotes, or just using commas to separate them.

My version of ps, on Linux, is 2.0.10.

Danek

Re: Preventing sorting in completers

[Bart Schaefer]

On Jul 14,  9:11am, Danek Duvall wrote:
} Subject: Re: Preventing sorting in completers
}
} Peter Stephenson wrote:
} 
} > Bart Schaefer wrote:
} > > } zstyle ":completion:*:processes" command \
} > > }   'ps -u $UID -o ''pid tty s args'' --forest'
} > > 
} > > ERROR: TTY could not be found.
} > 
} > My guess is your system is using stdout to decide what the tty is
} 
} I would guess that the double single quotes that Philippe is using
} should probably be single quotes escaped by backslashes

Aha.  I should have noticed that.

Philippe has 'setopt rcquotes' and I do not.

Re: Preventing sorting in completers

[Peter Stephenson]

Peter Stephenson wrote:
> I suspect what we want to do is test for an explicitly set sort style in
> _description and used that to override the default.  Then we can all
> forget about tweaking the functions.

For example, the following very lightly tested function where I've tried
not to screw up _expand but fell into apathy at the thought of actually
testing whether I had.

I think this makes the direct use in _history redundant.

Index: Completion/Base/Core/_description
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_description,v
retrieving revision 1.4
diff -u -r1.4 _description
--- Completion/Base/Core/_description	12 Feb 2002 13:37:03 -0000	1.4
+++ Completion/Base/Core/_description	14 Jul 2003 16:38:30 -0000
@@ -1,6 +1,6 @@
 #autoload
 
-local name gropt nopt xopt format gname hidden hide match opts tag
+local name gropt nopt xopt format gname hidden hide match opts tag sort
 
 opts=()
 
@@ -30,6 +30,16 @@
 zstyle -s ":completion:${curcontext}:$1" matcher match &&
     opts=($opts -M "$match")
 [[ -n "$_matcher" ]] && opts=($opts -M "$_matcher")
+
+# Use sort style, but ignore `menu' value to help _expand.
+if zstyle -s ":completion:${curcontext}:$1" sort sort &&
+    [[ $sort != menu ]]; then
+    if [[ "$sort" = (yes|true|1|on) ]]; then
+	gropt=(-J)
+    else
+	gropt=(-V)
+    fi
+fi
 
 if [[ -z "$_comp_no_ignore" ]]; then
   zstyle -a ":completion:${curcontext}:$1" ignored-patterns _comp_ignore ||
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.171
diff -u -r1.171 compsys.yo
--- Doc/Zsh/compsys.yo	7 Jul 2003 09:48:46 -0000	1.171
+++ Doc/Zsh/compsys.yo	14 Jul 2003 16:38:30 -0000
@@ -2162,12 +2162,19 @@
 )
 kindex(sort, completion style)
 item(tt(sort))(
-If set to `true', completing words from the command
-history sorts the words alphabetically instead of
+Many completion widgets call tt(_description) at some point which
+decides whether the matches are added sorted or unsorted (often
+indirectly via tt(_wanted) or tt(_requested)).  This style can be set
+explicitly to one of the usual true or false values as an override.
+If it is not set for the context, the standard behaviour of the
+calling widget is used.
+
+When completing words from the command
+history, if set to `true' the words are sorted alphabetically instead of
 keeping them in the order in which they appear in the history (from
 youngest to oldest).
 
-This is also used by the tt(_expand) completer. If it is set to
+In the tt(_expand) completer, if it is set to
 `true', the expansions generated will always be sorted.  If it is set
 to `tt(menu)', then the expansions are only sorted when they are offered 
 as single strings but not in the string containing all possible


-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
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: Preventing sorting in completers

[Bart Schaefer]

On Jul 14,  5:41pm, Peter Stephenson wrote:
} Subject: Re: Preventing sorting in completers
}
} For example, the following very lightly tested function where I've tried
} not to screw up _expand but fell into apathy at the thought of actually
} testing whether I had.

I think what you've done will change the behavior of _expand in those
cases where the internal sort done by the completion system does not
agree with the sort performed by ${(o)exp}.  Depending on the context
used to set the style, of course.

I'm not sure what the other ramifications of the zstyle context may be;
_expand uses

    zstyle -s ":completion:${curcontext}:" sort sort

whereas with the patch _description uses

    zstyle -s ":completion:${curcontext}:$1" sort sort
 
} I think this makes the direct use in _history redundant.

Not quite, because _history also uses the shorter context name:

    if zstyle -t ":completion:${curcontext}:" sort; then

Is there an obvious way to resolve that, without breaking working styles?

Re: Preventing sorting in completers

[Peter Stephenson]

Bart Schaefer wrote:
> I think what you've done will change the behavior of _expand in those
> cases where the internal sort done by the completion system does not
> agree with the sort performed by ${(o)exp}.  Depending on the context
> used to set the style, of course.

I assumed that (o) was equivalent to what the completion system did.

> I'm not sure what the other ramifications of the zstyle context may be;
> _expand uses
> 
>     zstyle -s ":completion:${curcontext}:" sort sort
> 
> whereas with the patch _description uses
> 
>     zstyle -s ":completion:${curcontext}:$1" sort sort

Well, the only ways I can see of completely removing problems like this
are to pass down an additional argument into _description and _wanted to
stop it using the style, or use a different style.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
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: Preventing sorting in completers

[Bart Schaefer]

On Jul 14,  6:31pm, Peter Stephenson wrote:
} Subject: Re: Preventing sorting in completers
}
} Bart Schaefer wrote:
} > cases where the internal sort done by the completion system does not
} > agree with the sort performed by ${(o)exp}.
} 
} I assumed that (o) was equivalent to what the completion system did.

It may very well be, and most likely is.
 
} > _expand uses
} >     zstyle -s ":completion:${curcontext}:" sort sort
} > whereas with the patch _description uses
} >     zstyle -s ":completion:${curcontext}:$1" sort sort
} 
} Well, the only ways I can see of completely removing problems like this
} are to pass down an additional argument into _description and _wanted to
} stop it using the style, or use a different style.

These aren't necessarily problems to be removed, just behaviors to be
documented.  There's no reason one can't have a style for sorting the
results of _expand and another more specific style for sorting a tag
context.

OTOH, I wonder whether _description should NOT use the style when an
explicit -J or -V argument has been passed?  Most of the time there is
no -J/-V argument at all to _description.

Re: Preventing sorting in completers

[Philippe Troin]

Peter Stephenson <pws@csr.com> writes:

> Peter Stephenson wrote:
> > I suspect what we want to do is test for an explicitly set sort style in
> > _description and used that to override the default.  Then we can all
> > forget about tweaking the functions.
> 
> For example, the following very lightly tested function where I've tried
> not to screw up _expand but fell into apathy at the thought of actually
> testing whether I had.

The patch for _description for for me, but I'm lost w.r.t. its
implications for _expand().

Phil.

Re: Preventing sorting in completers

[Peter Stephenson]

Bart Schaefer wrote:
> } Well, the only ways I can see of completely removing problems like this
> } are to pass down an additional argument into _description and _wanted to
> } stop it using the style, or use a different style.
> 
> These aren't necessarily problems to be removed, just behaviors to be
> documented.  There's no reason one can't have a style for sorting the
> results of _expand and another more specific style for sorting a tag
> context.

It occurred to me we could test with the tag, then without, for
compatibility; something similar is done in other places, though usually
with some default tag.

> OTOH, I wonder whether _description should NOT use the style when an
> explicit -J or -V argument has been passed?  Most of the time there is
> no -J/-V argument at all to _description.

That's certainly arguable, but there's still something to be said for
giving people control anyway, in the same way you can override the set
of matched files.  I think the question is: are people likely to use a
general enough context that it gives unexpected effects with sorting
elsewhere?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
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: Preventing sorting in completers

[Bart Schaefer]

On Jul 15, 10:42am, Peter Stephenson wrote:
}
} It occurred to me we could test with the tag, then without, for
} compatibility; something similar is done in other places, though
} usually with some default tag.

That'd be reasonable, though it still requires the special case for
"menu" for _expand and therefore we can't remove code from _expand.
We might be able to remove it from _history.

} > OTOH, I wonder whether _description should NOT use the style when
} > an explicit -J or -V argument has been passed?
} 
} That's certainly arguable, but there's still something to be said
} for giving people control anyway, in the same way you can override
} the set of matched files.

Slightly revised suggestion:  Allow styles to override an explicit -J,
but do not allow overriding an explicit -V.  I did a quick grep, and
there are very few cases where the -V option is passed; but in none of
those would it be useful to apply a sort.

} I think the question is: are people likely to use a general enough
} context that it gives unexpected effects with sorting elsewhere?

Considering that in nearly all cases the style would be used to turn
sorting _off_ rather than _on_, that strikes me as unlikely.  However,
there are cases (e.g., _gdb) where nearly all contexts are sorted but
one specific one (baud rate values) is unsorted, so if the style _is_
used to enable sorting, the possibility does exist.

Re: Preventing sorting in completers

[Peter Stephenson]

Bart Schaefer wrote:
> Slightly revised suggestion:  Allow styles to override an explicit -J,
> but do not allow overriding an explicit -V.  I did a quick grep, and
> there are very few cases where the -V option is passed; but in none of
> those would it be useful to apply a sort.

I've now ended up with the following.  The special history code is still
necessary because it reverses the usual default; it assumes you don't
want it sorted unless you say you do.

Index: Completion/Base/Core/_description
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_description,v
retrieving revision 1.4
diff -u -r1.4 _description
--- Completion/Base/Core/_description	12 Feb 2002 13:37:03 -0000	1.4
+++ Completion/Base/Core/_description	15 Jul 2003 18:32:02 -0000
@@ -1,6 +1,6 @@
 #autoload
 
-local name gropt nopt xopt format gname hidden hide match opts tag
+local name gropt nopt xopt format gname hidden hide match opts tag sort
 
 opts=()
 
@@ -30,6 +30,18 @@
 zstyle -s ":completion:${curcontext}:$1" matcher match &&
     opts=($opts -M "$match")
 [[ -n "$_matcher" ]] && opts=($opts -M "$_matcher")
+
+# Use sort style, but ignore `menu' value to help _expand.
+# Also don't override explicit use of -V.
+if { zstyle -s ":completion:${curcontext}:$1" sort sort ||
+     zstyle -s ":completion:${curcontext}:" sort sort; } &&
+    [[ "$gropt" = -J && $sort != menu ]]; then
+    if [[ "$sort" = (yes|true|1|on) ]]; then
+	gropt=(-J)
+    else
+	gropt=(-V)
+    fi
+fi
 
 if [[ -z "$_comp_no_ignore" ]]; then
   zstyle -a ":completion:${curcontext}:$1" ignored-patterns _comp_ignore ||
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.171
diff -u -r1.171 compsys.yo
--- Doc/Zsh/compsys.yo	7 Jul 2003 09:48:46 -0000	1.171
+++ Doc/Zsh/compsys.yo	15 Jul 2003 18:32:02 -0000
@@ -2162,12 +2162,22 @@
 )
 kindex(sort, completion style)
 item(tt(sort))(
-If set to `true', completing words from the command
-history sorts the words alphabetically instead of
-keeping them in the order in which they appear in the history (from
-youngest to oldest).
+Many completion widgets call tt(_description) at some point which
+decides whether the matches are added sorted or unsorted (often
+indirectly via tt(_wanted) or tt(_requested)).  This style can be set
+explicitly to one of the usual true or false values as an override.
+If it is not set for the context, the standard behaviour of the
+calling widget is used.
 
-This is also used by the tt(_expand) completer. If it is set to
+The style is tested first against the full context including the tag, and
+if that fails to produce a value against the context without the tag.
+
+If the calling widget explicitly requests unsorted matches, this is usually
+honoured.  However, the default (unsorted) behaviour of completion
+for the command history may be overridden by setting the style to
+tt(true).
+
+In the tt(_expand) completer, if it is set to
 `true', the expansions generated will always be sorted.  If it is set
 to `tt(menu)', then the expansions are only sorted when they are offered 
 as single strings but not in the string containing all possible

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
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: Preventing sorting in completers

[Philippe Troin]

Any reason why this has not made it into cvs as of July 22 2003?

Phil.

Peter Stephenson <pws@csr.com> writes:

> Bart Schaefer wrote:
> > Slightly revised suggestion:  Allow styles to override an explicit -J,
> > but do not allow overriding an explicit -V.  I did a quick grep, and
> > there are very few cases where the -V option is passed; but in none of
> > those would it be useful to apply a sort.
> 
> I've now ended up with the following.  The special history code is still
> necessary because it reverses the usual default; it assumes you don't
> want it sorted unless you say you do.
> 
> Index: Completion/Base/Core/_description
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_description,v
> retrieving revision 1.4
> diff -u -r1.4 _description
> --- Completion/Base/Core/_description	12 Feb 2002 13:37:03 -0000	1.4
> +++ Completion/Base/Core/_description	15 Jul 2003 18:32:02 -0000
> @@ -1,6 +1,6 @@
>  #autoload
>  
> -local name gropt nopt xopt format gname hidden hide match opts tag
> +local name gropt nopt xopt format gname hidden hide match opts tag sort
>  
>  opts=()
>  
> @@ -30,6 +30,18 @@
>  zstyle -s ":completion:${curcontext}:$1" matcher match &&
>      opts=($opts -M "$match")
>  [[ -n "$_matcher" ]] && opts=($opts -M "$_matcher")
> +
> +# Use sort style, but ignore `menu' value to help _expand.
> +# Also don't override explicit use of -V.
> +if { zstyle -s ":completion:${curcontext}:$1" sort sort ||
> +     zstyle -s ":completion:${curcontext}:" sort sort; } &&
> +    [[ "$gropt" = -J && $sort != menu ]]; then
> +    if [[ "$sort" = (yes|true|1|on) ]]; then
> +	gropt=(-J)
> +    else
> +	gropt=(-V)
> +    fi
> +fi
>  
>  if [[ -z "$_comp_no_ignore" ]]; then
>    zstyle -a ":completion:${curcontext}:$1" ignored-patterns _comp_ignore ||
> Index: Doc/Zsh/compsys.yo
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
> retrieving revision 1.171
> diff -u -r1.171 compsys.yo
> --- Doc/Zsh/compsys.yo	7 Jul 2003 09:48:46 -0000	1.171
> +++ Doc/Zsh/compsys.yo	15 Jul 2003 18:32:02 -0000
> @@ -2162,12 +2162,22 @@
>  )
>  kindex(sort, completion style)
>  item(tt(sort))(
> -If set to `true', completing words from the command
> -history sorts the words alphabetically instead of
> -keeping them in the order in which they appear in the history (from
> -youngest to oldest).
> +Many completion widgets call tt(_description) at some point which
> +decides whether the matches are added sorted or unsorted (often
> +indirectly via tt(_wanted) or tt(_requested)).  This style can be set
> +explicitly to one of the usual true or false values as an override.
> +If it is not set for the context, the standard behaviour of the
> +calling widget is used.
>  
> -This is also used by the tt(_expand) completer. If it is set to
> +The style is tested first against the full context including the tag, and
> +if that fails to produce a value against the context without the tag.
> +
> +If the calling widget explicitly requests unsorted matches, this is usually
> +honoured.  However, the default (unsorted) behaviour of completion
> +for the command history may be overridden by setting the style to
> +tt(true).
> +
> +In the tt(_expand) completer, if it is set to
>  `true', the expansions generated will always be sorted.  If it is set
>  to `tt(menu)', then the expansions are only sorted when they are offered 
>  as single strings but not in the string containing all possible

Re: Preventing sorting in completers

[Peter Stephenson]

Philippe Troin wrote:
> Any reason why this has not made it into cvs as of July 22 2003?

It was committed on the 21st.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
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: Preventing sorting in completers

[Philippe Troin]

Peter Stephenson <pws@csr.com> writes:

> Philippe Troin wrote:
> > Any reason why this has not made it into cvs as of July 22 2003?
> 
> It was committed on the 21st.

Thanks, I can see it in CVS now.

Phil.

CVS (Re: Preventing sorting in completers)

[Oliver Kiddle]

Philippe Troin wrote:
> Peter Stephenson <pws@csr.com> writes:
> 
> > Philippe Troin wrote:
> > > Any reason why this has not made it into cvs as of July 22 2003?
> > 
> > It was committed on the 21st.
> 
> Thanks, I can see it in CVS now.

This'll be due to the anonymous CVS server at sourceforge being a
separate server which doesn't use the live repository. So it's up to a
few days out-of-date.

To what extent is that a problem? Connecting to the anonymous server
seems to at least work now, albeit slowly.

Oliver

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________