PATCH: Re: Open bugs and questions?

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> ...
> 
> I haven't updated the one I made just before 3.1.9, but I don't think
> everything on that last list got done, either.

Hmhm.

> } 12344, 12350, 12382
> }   Make `_arguments --' use the short options, too?
> 
> I have a patch for this first part, but:
> 
> }   And make it prefer a user-supplied description if there is one (and
> }   a automatically found one).
> 
> I don't have a patch for that second part.

Below is the patch for it. It makes user-supplied specs be preferred
unconditionally, though, even if there is a spec matching the option
after the `--' (that's the problem: `matching', probably user didn't
mean that or it's one of the two builtin patterns for files and
paths).

Two comments: I had to use `let' because stuffing that parameter
expansion into a `((...))'' wasn't parsed correctly. And: how do you
specify a character class matching everything but ']'?


> } 12225
> }   The return value of _arguments with `->state' actions doesn't tell
> }   if options were completed.
> 
> I meant to reply to that message.  I've never been happy with using the
> exit status to indicate that an ->state action was taken.  The only
> simple test on exit status is true/false; for anything else, you have
> to compare against $? -- which means you might as well be testing some
> other parameter instead, e.g. [[ -n "$state" ]] which is what most of
> the functions that use ->state already do anyway.
> 
> So I suggest simply dumping the 300 exit status; zero means that matches
> were added, anything else means that no matches were added, and if you
> want to use states you test the $state array directly.

No. The special return value is used by the wrappers around _arguments 
such as _x_arguments. And there we *need* to be able to distinguish
the cases (to keep the special parameters from being reset).

And anyway, the problem is not with the return value, since, as you
observed, we use $state for tests anyway. The problem is that with
->state actions _arguments may have to generate matches (the options)
and it can't know if the caller adds more matches. What I wanted is an 
easier way for calling functions to distinguish this from the case
where _arguments generates real matches (by executing one of the other 
forms for actions). Currently this can be done by relying on the
return value to test if `real' matches (not only options) were
generated and then use $state to find out if a state has to be handled 
and *there* use $compstate[nmatches] to find out if options were
completed. If needed, and it is seldom needed because in most cases
the state doesn't have to be handled in a loop.

> } 12054, 12071
> }   There is no way to handle ^D at the beginning of the line with a
> }   widget, because the zle main loop deals with it directly.
> 
> It *is* possible to handle ^D at beginning of line:  stty eof undef
> permits it.  This is equivalent to having to turn off flow control in
> order to use ^S and ^Q in keybindings.
> 
> So maybe the right answer is that `setopt ignoreeof' should affect ZLE
> the same way that `setopt noflowcontrol' does.  An actual zero-byte
> read would still be handled as it currently is; only ^D in column zero
> would be different (actually invoke the ^D binding rather than print
> "zsh: use 'logout' to logout.").

Sounds good.

> THEN we could change delete-char-or-list to print that warning when there
> are no characters in the editor buffer, et voila: the default behavior is
> exactly as now.

And the other widgets that are bound to ^D by default (in vi mode).

> ...
> 
> } 11399, 11400, 11413, 11428
> }   Context names for styles not used by the completion system
> }   itself. More specifically, for function that call the completion
> }   system, but have other styles used directly. And where to document
> }   them.
> 
> I've been toying with the idea of adding a "user contributions" chapter
> to the manual and throwing into it: incremental-complete-word, zed, the
> prompt themes, predict-on, zrecompile, nslookup, etc.  With appropriate
> sections, of course.

Sounds good, too.

> } 11465
> }   Interrupting builtins. E.g. with `cmd1 | builtin ; cmd2' a ^C should 
> }   keep cmd2 from being run.
> 
> There's also 11468.  I wish I had a suggestion.

I thought I had replied to it at the time, but it seems I didn't. To
repeat, the problem mentioned in 11468 was (quoting Bart):

> zagzig% cat | while read line; do echo $line; done; :
> ^Z^C
> zsh: suspended  cat | 
> zsh: running    while read line; do; echo $line; done
> zagzig% jobs
> [1]  + suspended  cat | 
>        running    while read line; do; echo $line; done
> zagzig% fg
> [1]  + continued  cat | while read line; do; echo $line; done
> foo
> zagzig% 
> 
> 
> According to Etc/BUGS, the `; :' forces zsh to fork before starting the
> while loop.  So in that case I would have expected ^Z to work, but it
> doesn't.  Following the ^Z with a ^C appears to background the job, but
> that hasn't really happened either; the while loop is not running, it's
> already gotten a failure return from read.  Is it sitting there waiting
> for "cat" to die?   (Which cat does, from a closed stdout, I think, as
> soon as you give it any input.)

First of all the `; :' is mentioned only for `zsh -c', but I admit
that I didn't try it with 3.0.8. With current CVS I get that thing
suspended on the ^Z, but foregrounding it gives the same result as
what Bart describes above. This is because in update_job(),
jobs.c:32[89] breaks and errflag are set because val is -1. This makes 
the test in zread(), builtin.c:3774 fail and read returns with a
non-zero status, ending the loop.

Changing the test in update_job() is, of course, trivial, but the read 
becomes unsuspensible. Ick.

Bye
 Sven

Index: Completion/Base/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/_arguments,v
retrieving revision 1.30
diff -u -r1.30 _arguments
--- Completion/Base/_arguments	2000/08/01 11:21:00	1.30
+++ Completion/Base/_arguments	2000/08/02 08:43:30
@@ -70,7 +70,18 @@
     lopts=("--${(@)^${(@)${(@)${(@M)${(@ps:\n:j:\n:)${(@)${(@M)${(@f)$(_call options ${~words[1]} --help 2>&1)//\[--/
 --}:#[ 	]#-*}//,/
 }}:#[ 	]#--*}#*--}%%[]	 ]*}:#}")
-    lopts=( "${(@)lopts:#--}" )
+
+    # Remove options also described by user-defined specs.
+
+    tmp=()
+    for opt in "${(@)lopts:#--}"; do
+
+      # Using (( ... )) gives a parse error.
+
+      let "$tmpargv[(I)(|\([^\)]#\))${opt}(|[-+=])(|\[*\])(|:*)]" ||
+          tmp=( "$tmp[@]" "$opt" )
+    done
+    lopts=( "$tmp[@]" )
 
     # Now remove all ignored options ...
 

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx