Re: Job Table

Re: Job Table

[Sven Wischnowsky]

Nick Cross wrote:

> I'm running 3.1.9 and keep getting job table full messages - how do I
> increase the limit?

Change the setting of MAXJOB in config.h or re-configure using
--enable-max-jobtable-size=<number> (and then re-build the shell).

Hm, do you really need more than 48 jobs? (The default for MAXJOB is
50, two of them are used internally.)

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

completion with globbing, take 2

[E. Jay Berkenbilt]

Several days ago, I wanted to know how I could get zsh to respond to 

something *TAB

by replacing the * with the list everything that the completion system
would return instead of everything * would match in the current
directory.  I was told to do this:

zstyle ':completion:*' completer _oldlist _complete _match
bindkey "^I" complete-word

I've spent a lot of time trying to figure this out, but this still
doesn't work and I don't know how to make it work.  This gives a
behavior like menu-complete.  I never want menu-complete-like
functionality.  I want behavior more like what expand-or-complete does
except that I want only what the completion system would return to be
substituted.

I will be very explicit to reduce the chance of my question being
misunderstood.

zsh -f

> zsh% autoload -U compinit
> zsh% compinit
> zsh% mkdir /tmp/z
> zsh% cd /tmp/z
> zsh% mkdir 1 2 3
> zsh% touch a b c

Type:

> zsh% rmdir TAB

You see:

> zsh% rmdir 
> 1/  2/  3/

Type:

> zsh% rmdir *TAB

You see:

> zsh% rmdir 1 2 3 a b c 

Now configure as above:

> zsh% zstyle ':completion:*' completer _oldlist _complete _match
> zsh% bindkey "^I" complete-word

Type:

> zsh% rmdir *TAB

You see:

> zsh% rmdir 1/
1/  2/  3/

Each subsequent TAB rotates between 1/, 2/, and 3/.

What I want:

> zsh% rmdir *TAB

should yield

> zsh% rmdir 1 2 3 

Is there a way to do this?

--
E. Jay Berkenbilt (ejb@ql.org)  |  http://www.ql.org/q/

Re: completion with globbing, take 2

[Bart Schaefer]

On Sep 17,  1:50pm, E. Jay Berkenbilt wrote:
}
} Several days ago, I wanted to know how I could get zsh to respond to 
} 
} something *TAB
} 
} by replacing the * with the list everything that the completion system
} would return instead of everything * would match in the current
} directory.  I was told to do this:
} 
} zstyle ':completion:*' completer _oldlist _complete _match
} bindkey "^I" complete-word

More precisely, you were told that Andrej does that.

Andrej probably wasn't expecting you to use it verbatim, though, because
he didn't show you what his settings for the matcher-list style are.  You
didn't say whether you have any settings for matcher-list; if you don't,
the _match completer won't do anything.

} I want behavior more like what expand-or-complete does except that I
} want only what the completion system would return to be substituted.

That's what the _expand completer is for.  I believe you want:

zstyle ':completion:*' completer _oldlist _expand _complete _match
zstyle ':completion::expand:*' completions true

And maybe you don't even need the _match on the end, if you haven't
worked out any matcher-list values yet.  The _match completer is for
doing things like case-insensitive completion and completion of sub-
parts of file names (e.g., completing on both sides of a ".").

You probably also want to read about the following styles:

    accept-exact
    add-space
    completions
    glob
    keep-prefix
    sort
    subst-globs-only
    substitute
    suffix

-- 
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: completion with globbing, take 2

[E. Jay Berkenbilt]

Okay, with everyone's help, my problem is solved, but the solution
brings up lots of questions.


>   } Several days ago, I wanted to know how I could get zsh to respond to 
>   } 
>   } something *TAB
>   } 
>   } by replacing the * with the list everything that the completion system
>   } would return instead of everything * would match in the current
>   } directory.  I was told to do this:
>   } 
>   } zstyle ':completion:*' completer _oldlist _complete _match
>   } bindkey "^I" complete-word
>
>   More precisely, you were told that Andrej does that.
>
>   Andrej probably wasn't expecting you to use it verbatim, though, because
>   he didn't show you what his settings for the matcher-list style are.  

Right.

>   You
>   didn't say whether you have any settings for matcher-list; if you don't,
>   the _match completer won't do anything.

Sorry -- my original message failed to say that I was starting with
zsh -f with only the completion system loaded and no additional
customization.  This is why I was much more explicit in my second
message.

Also, after reading the code, I don't believe it is true that _match
won't do anything without matcher-list set -- see analysis and
questions below.

>   } I want behavior more like what expand-or-complete does except that I
>   } want only what the completion system would return to be substituted.
>
>   That's what the _expand completer is for.  I believe you want:
>
>   zstyle ':completion:*' completer _oldlist _expand _complete _match
>   zstyle ':completion::expand:*' completions true

This almost worked, and it gave me enough additional information to
get the rest of the way there.  I now have the following:

  zstyle ':completion:*' completer _oldlist _complete _expand _match
  zstyle ':completion::expand:*' completions true
  bindkey "^I" complete-word

This seems to do exactly what I'm looking for.  We'll see whether I've
broken anything.

Removing any of _complete, _expand, or _match or changing the order in
which they appear breaks things.

Now I've analyzed the code and think I understand why this works, but
I'm not 100% certain.  Interestingly, ^X? doesn't work when I do

rmdir *^X?

but that's okay -- I just did setopt xtrace and then

rmdir *TAB

Again, I have just 1, 2, 3, a, b, and c in the currently directory
where 1, 2, and 3 are directories and a, b, and c are files.

Looking at the trace and the code, here's what I think is happening:

_main_complete is called.  It looks up my completers (_oldlist,
_complete, _expand, and _match) and calls then in order.  _oldlist
returns nothing, _complete returns nothing (since no files start with
'*').  Now it starts getting interesting.  _expand is called.  Since I
have set the completions style for expand to true, it sets
compstate[insert]=all which gives me the behavior I'm looking for with
respect to the replacement.  However, since the current context is not
expand-word:*, it does not call _complete and thus just returns 1.
Finally, _match is called.  I don't follow exactly what's going on at
the top of _match, but it doesn't matter.  Since I don't have
match-original set, _match sets compstate[pattern_match]='*' and calls
_complete again.  This time, since compstate[pattern_match] is set,
_complete actually does find matches.

So the right thing happens, but the path to the desired end seems
quite convoluted and counterintuitive to me.  I would never have
figured this out without the significant hints without having to spend
a lot of time grokking this code.

So there end up being two important commands here.  Without this one:

  zstyle ':completion::expand:*' completions true

the call to _expand doesn't set compstate[insert]=all.  Now if I look
at this:

  zstyle ':completion:*' completer _oldlist _complete _expand _match

If we remove _match, then _complete never gets called again with
compstate[pattern_match]='*', so it is essential.  If _expand appears
before _complete, then 

rmdir TAB

by itself inserts all the matches.

So, in summary, it seems that the only thing I'm using expand for is
to get compstate[insert]=all.  The only thing I'm using _match for is
to get _complete to be called with with compstate[pattern_match]='*'.
I can't do this with setopt glob_complete because if I do, then the
first call to _complete will generate matches when it is called before
the call to _expand, so I'll get the menu behavior instead of what I
wanted.  If I put _expand before _complete with these settings, I
always get all matches substituted (as if I had typed the *), which
renders the completion system pretty useless.

So, is my analysis correct?  Am I getting behavior that was intended
here, or have I just stumbled upon a way to do this?  I feel like I'm
getting the desired behavior through a series of coincidences and that
this could change or break pretty easily in the future....

Thanks for all the help.

                                Jay

completion and globbing, part 2

[E. Jay Berkenbilt]

It occurred to me that if the analysis in my last message was true,
the following would work:

zstyle ':completion:*' completer _oldlist _complete _qcomp _ignored
bindkey "^I" complete-word

where _qcomp is defined as follows:

   #autoload

   compstate[pattern_match]='*'
   compstate[insert]=all
   ret=1
   _complete && ret=0
   return ret

This does, in fact, give me exactly the behavior I'm looking for
without using _expand or _match.

(I also added _ignored, but that doesn't have anything to do with
this.)

--
E. Jay Berkenbilt (ejb@ql.org)  |  http://www.ql.org/q/

RE: completion with globbing, take 2

[Andrej Borsenkow]

>
> More precisely, you were told that Andrej does that.
>

First, I must apologize for wrong advice (you should not answer such questions
at 10pm :-( And I misunderstood the question anyway.

> Andrej probably wasn't expecting you to use it verbatim, though, because
> he didn't show you what his settings for the matcher-list style are.  You
> didn't say whether you have any settings for matcher-list; if you don't,
> the _match completer won't do anything.
>

No, wrong. _match has absolutely nothing to do with matcher-list style (that
was introduced only recently). _match was first "alternative" for
GLOB_COMPLETE option. It tries to match the list of possible completions
against pattern on command line. This works for _every_ completion (while
GLOB_COMPLETE worked only for files). But _match never tries to *expand* the
pattern - that is what _expand is for.

matcher-list is used to set global "matchers" - e.g. to do case-insensitive or
partial-word completion, like completing c-w to complete-word :-)) or g_c to
G_c to globcomplete.

> } I want behavior more like what expand-or-complete does except that I
> } want only what the completion system would return to be substituted.
>

Thinking about it, I believe, that _match would be the correct completer to do
it. There are many cases where we simply cannot do expansion at all - option
names, widget names etc etc etc. So, consider something like

setopt *complete*TAB

WIth _match this enters menu completion - but _expand_word (I tried it) gives
you nothing. So, there seems to be no way to just insert all matching choices.
While _expand (and friends) may be useful at times, _match just seems to be
more powerful. (Of course, another general solution is to have widget that
would insert all listed choices at once. Was not it discussed once?)


> That's what the _expand completer is for.  I believe you want:
>
> zstyle ':completion:*' completer _oldlist _expand _complete _match
> zstyle ':completion::expand:*' completions true
>

Actually, no. It works in this case only because file completion itself is
using globbing - that is, the set of possible matches is determined by pattern
on command line. But the original wish was:

	the * gets replaced with all the choices that the completion system
	returns at that time (i.e., whatever glob pattern I've typed should be
	applied to the completion choices rather than to files)?

It is exactly what _match does ... without giving you the way to insert all
choices.

> And maybe you don't even need the _match on the end, if you haven't
> worked out any matcher-list values yet.  The _match completer is for
> doing things like case-insensitive completion and completion of sub-
> parts of file names (e.g., completing on both sides of a ".").
>

No. See above the description of _match.

-andrej

RE: completion and globbing, part 2

[Andrej Borsenkow]

>
>
> It occurred to me that if the analysis in my last message was true,
> the following would work:
>
> zstyle ':completion:*' completer _oldlist _complete _qcomp _ignored
> bindkey "^I" complete-word
>
> where _qcomp is defined as follows:
>
>    #autoload
>
>    compstate[pattern_match]='*'
>    compstate[insert]=all
>    ret=1
>    _complete && ret=0
>    return ret
>
> This does, in fact, give me exactly the behavior I'm looking for
> without using _expand or _match.
>
> (I also added _ignored, but that doesn't have anything to do with
> this.)
>


In this case, you, probably, do not need _oldlist either.

Well, what you've effectively done is to write stripped-down version of _match
:-) Could you consider patching _match adding a style to control it? But,
really, it may not be as simple. _expand gives you choice to select all
expantions as a tag. But _match just modifies behaviour of subsequent
completer ... I mean, general implementation should give a choice to insert or
not to insert all matching completions. I currently do not see place to put it
in.

May be, widget to do it (insert all current choices) would be the simplest
case. Hmm ... may be it is even possible to implement it as function.

-andrej

insert-all-matches example RE: completion and globbing, part 2

[Andrej Borsenkow]

>
> May be, widget to do it (insert all current choices) would be the simplest
> case. Hmm ... may be it is even possible to implement it as function.
>

Very dumb implemetation. It won't work (correctly) if anything is already
inserted on command line - that is, it will insert all matches directly after
anything already there. This may or may not be appropriate.

bor@itsrm2% which _insert_all_matches
_insert_all_matches () {
        compstate[insert]=all
        compstate[old_list]=keep
        _complete
}
bor@itsrm2% zle -C insert-all-matches complete-word _insert_all_matches
bor@itsrm2% bindkey '^Xi' insert-all-matches

With these you could do:

bor@itsrm2% ls f*^D
bor@itsrm2% ls f*
Completing file
fnt/    foo.c

Now press ^Xi

bor@itsrm2% ls fnt foo.c

But, as stated, it has all sorts of problems. It does not work correctly after
*completion* - it tries to complete word already inserted (that is, it is
treated as new completion instead of continuation of old - but this may be
related to my styles settings).  ^D is needed to get a list that is inserted
with ^Xi.

-andrej

Re: completion with globbing, take 2

[Bart Schaefer]

On Sep 17,  7:03pm, E. Jay Berkenbilt wrote:
}
} Also, after reading the code, I don't believe it is true that _match
} won't do anything without matcher-list set -- see analysis and
} questions below.

Right, I was confused, as Andrej has already pointed out.  (The completion
system has a tendency to do that to almost anyone from time to time, even
Sven.)
 
} Now I've analyzed the code and think I understand why this works, but
} I'm not 100% certain.  Interestingly, ^X? doesn't work when I do
} 
} rmdir *^X?

I believe _complete_debug actually did work, but _message did not (and
therefore you didn't see the "Trace output left in ..." message).  If
you try it again and then immediately hit C-p (up-line-or-history), you
should find that the command to view the trace file has in fact been
recorded.

}   zstyle ':completion:*' completer _oldlist _complete _expand _match
} 
} If we remove _match, then _complete never gets called again with
} compstate[pattern_match]='*', so it is essential.  If _expand appears
} before _complete, then 
} 
} rmdir TAB
} 
} by itself inserts all the matches.

Yes, I was a bit surprised by that myself -- I think it must be a bug.
I don't think the _expand completer should do anything when there's no
prefix nor a suffix.

On Sep 17,  8:17pm, E. Jay Berkenbilt wrote:
} Subject: completion and globbing, part 2
}
} It occurred to me that if the analysis in my last message was true,
} the following would work:
[...]
} This does, in fact, give me exactly the behavior I'm looking for
} without using _expand or _match.

Does it?  What happens when you complete a pattern that matches only
directories?  (I get, it inserts all the directories and adds a slash
after only the last one, so if I press TAB again I get completions in
that last directory, which seems unlikely to be what you'd want.)

Incidentally, the three lines

   ret=1
   _complete && ret=0
   return ret

are equivalent to just

   _complete
   return

and if _complete is the last line in the function, you don't even need
the `return'.

On Sep 18, 10:07am, Andrej Borsenkow wrote:
} Subject: RE: completion with globbing, take 2
}
} [...] consider something like
} 
} setopt *complete*TAB
} 
} WIth _match this enters menu completion - but _expand_word (I tried
} it) gives you nothing. So, there seems to be no way to just insert all
} matching choices.

As Jay discerned, `compstate[pattern_match]=\*' is all you need to get
the same effect as _match in this case.  The only additional stuff that
_match gets you (now that I'm thinking correctly about what it does) is
handling of the match-original and insert-unambiguous styles.

} While _expand (and friends) may be useful at times, _match just seems to be
} more powerful. (Of course, another general solution is to have widget that
} would insert all listed choices at once. Was not it discussed once?)

Only in the context of _expand, I think, which led to the all-expansions
tag.  The default behavior of _expand is to insert all the expansions and
then enter menu completion (with all the expansions being the first item
in the menu) so you can cycle away to just some of them if you prefer.

On Sep 18, 10:53am, Andrej Borsenkow wrote:
} Subject: RE: completion and globbing, part 2
}
} Well, what you've effectively done is to write stripped-down version of
} _match :-)

Not quite; he's written a stripped-down version of "_expand with the
completions style defaulted to true, followed by _match".

} Could you consider patching _match adding a style to control it?

The most obvious thing would be to have _match itself recognize the
completions style.

} But _match just modifies behaviour of subsequent completer ...

Eh?  It *calls* _complete.  How is that modifying subsequent completers?

On Sep 18,  1:59pm, Andrej Borsenkow wrote:
} Subject: insert-all-matches example RE: completion and globbing, part 2
}
} _insert_all_matches () {
}         compstate[insert]=all
}         compstate[old_list]=keep
}         _complete
} }
} bor@itsrm2% zle -C insert-all-matches complete-word _insert_all_matches
} bor@itsrm2% bindkey '^Xi' insert-all-matches

I get:

_files:54: no matches found: *:all-files

You have to remember to provide the standard completion-system setopts
in any wrapper around the supplied completer functions.

 _insert_all_matches () {
     setopt localoptions nullglob rcexpandparam extendedglob noshglob
     unsetopt markdirs globsubst shwordsplit nounset ksharrays
     compstate[insert]=all
     compstate[old_list]=keep
     _complete
 }

(Speaking of which, there's nullglob in the list.  Who was it who added
(N) to all those glob patterns in several functions?)

} But, as stated, it has all sorts of problems. It does not work correctly after
} *completion* - it tries to complete word already inserted (that is, it is
} treated as new completion instead of continuation of old - but this may be
} related to my styles settings).

Hmm ... can you give an example of what you see that you think is wrong?
It seems OK to me (and I'm curious which of your styles might botch it).

-- 
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: completion with globbing, take 2

[E. Jay Berkenbilt]

>   } Also, after reading the code, I don't believe it is true that _match
>   } won't do anything without matcher-list set -- see analysis and
>   } questions below.
>
>   Right, I was confused, as Andrej has already pointed out.  (The completion
>   system has a tendency to do that to almost anyone from time to time, even
>   Sven.)

Actually, I'll admit to being heartened to see others getting confused
about this.  It is pretty confusing. :-)

>   On Sep 17,  8:17pm, E. Jay Berkenbilt wrote:
>   } Subject: completion and globbing, part 2
>   }
>   } It occurred to me that if the analysis in my last message was true,
>   } the following would work:
>   [...]
>   } This does, in fact, give me exactly the behavior I'm looking for
>   } without using _expand or _match.
>
>   Does it?  What happens when you complete a pattern that matches only
>   directories?  (I get, it inserts all the directories and adds a slash
>   after only the last one, so if I press TAB again I get completions in
>   that last directory, which seems unlikely to be what you'd want.)

Well, in fact, I never do this with rmdir.  I chose it as an example
only because it's easy to work with and has simple completion
functions.  I really use this with cvs add and cvs rm where it is
great.  If I create a bunch of test files, I can do cvs add *TAB and
automatically not get the files that are already registered or files
that are in .cvsignore.  A great timesaver.  What I used to do is 
cvs add `cvs -qn update | fgrep '?' | awk '{print $2}'` (or something
like that) which isn't tooo bad but is obviously not as nice as cvs
add *TAB. :-)

>   Incidentally, the three lines
>
>      ret=1
>      _complete && ret=0
>      return ret
>
>   are equivalent to just
>
>      _complete
>      return
>
>   and if _complete is the last line in the function, you don't even need
>   the `return'.

Nice to know.  So I guess zsh functions are like lisp and perl -- the
value of the last statement is the return value -- but with the
additional feature that return with no arguments returns the last
value.... I'll have to play a bit to see what the real rules are or
check the documentation.  Over time as I gain more experience in more
languages and work with more people's code, I find myself
philosophically leaning more toward the Python mentality of making
everything explicit, but that's another topic for another forum....

--
E. Jay Berkenbilt (ejb@ql.org)  |  http://www.ql.org/q/

Re: completion with globbing, take 2

[Bart Schaefer]

On Sep 18,  6:07pm, E. Jay Berkenbilt wrote:
} Subject: Re: completion with globbing, take 2
}
} >   Does it?  What happens when you complete a pattern that matches only
} >   directories?
} 
} Well, in fact, I never do this with rmdir. [...]
} I really use this with cvs add and cvs rm where it is great.

So you have it restricted by style to :completion::complete:cvs* or
something like that?  I could see where that would be useful, but I
wouldn't want it in context :completion:* ...

I generally do the same thing by using accept-and-menu-complete.  Just
hit tab once, get the first completion, and then hit ^X TAB until all
the files have appeared.  That way I can selectively skip any that I don't
want to add, rather than inserting them all and then having to back up
and delete some.

    bindkey '^X^I' accept-and-menu-complete

} Nice to know.  So I guess zsh functions are like lisp and perl -- the
} value of the last statement is the return value -- but with the
} additional feature that return with no arguments returns the last
} value....

That's true of all Bourne-shell-like shells, actually.  At least, those
that have functions.

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

Job Table

[Nick Cross]

Hi,

I'm running 3.1.9 and keep getting job table full messages - how do I
increase the limit?

Cheers,

Nick