Default compctls

Default compctls

[Bart Schaefer]

Recent changes to compctl and to some other zsh behaviors lead me to ask
whether we should revise the default compctls.  Here's the current set:

compctl -b bindkey
compctl -c builtin
compctl -v export
compctl -o setopt
compctl -v typeset
compctl -v unset
compctl -o unsetopt
compctl -v vared
compctl -c which
compctl -C -c
compctl -D -f
compctl -T

First question:  Shouldn't that be `compctl -B builtin`?  If not, why not?

Next, an observation and (possibly) a bug:  The change to make `command',
`exec', `noglob', and `-' into builtins (rather than keywords) has caused
command completion for those words to stop working.  This would seem to
call for some new default compctls:

compctl -c -		# BUG!  `-' has special meaning to `compctl'!
compctl -m command
compctl -c exec
compctl -c noglob

Is there any workaround for the bug noted above?

Further, there doesn't seem to be any reason not to include the following
additional defaults:

compctl -j bg disown fg jobs kill wait
compctl -v declare integer local
compctl -aBFw disable
compctl -daBFw enable
compctl -F functions
compctl -Nv getln read
compctl -pv readonly
compctl -c sched
compctl -a unalias
compctl -F unfunction
compctl -cn unhash
compctl -p unset
compctl -c whence where

Particularly those last; why should `which' get a default completion, but
not `whence' or `where'?

As a final remark, it would be nice if `emulate', `limit', `trap' and
`ulimit' had some built-in equivalents of `compctl -k "(...)"' because
there's no obvious way to generate the lists of emulations or limits;
and `compctl -k "($(kill -l))" trap' is just re-using a list that was
already generated at compile time, so it might as well get compiled in
as a completion as well.

Comments?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Default compctls

[Zoltan Hidvegi]

> Recent changes to compctl and to some other zsh behaviors lead me to ask
> whether we should revise the default compctls.  Here's the current set:

I think compctls belong to the user-level code.  Adding new default
compctls just increase zsh size and it is quite useless as these are
usually overriden by the user.  Zsh is quite unusable without good startup
files anyway.  I change 28 options define 196 compctl's, 73 aliases and 57
functions and about 25 key bindings in my startup files.  The default
option setting is the worst.  I use the following options:

setopt LIST_TYPES AUTO_LIST LIST_AMBIGUOUS ALWAYS_LAST_PROMPT AUTO_MENU \
        AUTO_PARAM_KEYS EXTENDED_GLOB APPEND_HISTORY AUTO_CD CORRECT \
        NO_HUP MAGIC_EQUAL_SUBST NO_LIST_BEEP PUSHD_MINUS \
        RC_QUOTES LONG_LIST_JOBS HIST_IGNORE_DUPS NUMERIC_GLOB_SORT \
        COMPLETE_IN_WORD BRACE_CCL AUTO_NAME_DIRS NO_PROMPT_CR \
        AUTO_REMOVE_SLASH AUTO_PARAM_SLASH
unsetopt BG_NICE NOTIFY

> Next, an observation and (possibly) a bug:  The change to make `command',
> `exec', `noglob', and `-' into builtins (rather than keywords) has caused
> command completion for those words to stop working.  This would seem to
> call for some new default compctls:
> 
> compctl -c -		# BUG!  `-' has special meaning to `compctl'!
> compctl -m command
> compctl -c exec
> compctl -c noglob

I think -- should mean the end of completion flags as it already means that
with extended completions.  Note that Misc/compctl-examples contains better
compctl's for command, exec, moglob, -.  Look at the section near line 52.

> Is there any workaround for the bug noted above?

No, but

compctl -c exec -

works.

Zoltan

Re: Default compctls

[Zefram]

>compctl -c -		# BUG!  `-' has special meaning to `compctl'!

compctl -c - -

compctl -L will list it in this form too.


>Further, there doesn't seem to be any reason not to include the following
>additional defaults:
[...]

Actually, I don't see the point in having any default completions at
all (except for the -C, -D and -T completions, of course).  The
compctl-examples script already has completions for (almost?) all
builtins, and I'd rather not have the shell default to this fairly
arbitrary magic behaviour.  Besides, how clever should the default
completion for, say, `kill` be?  (Include signal names?  Process IDs?)

>As a final remark, it would be nice if `emulate', `limit', `trap' and
>`ulimit' had some built-in equivalents of `compctl -k "(...)"' because
>there's no obvious way to generate the lists of emulations or limits;
>and `compctl -k "($(kill -l))" trap' is just re-using a list that was
>already generated at compile time, so it might as well get compiled in
>as a completion as well.

There's already a list of signals available.  $signals[2,-3] is the
list of signals you can actually send to a process.  $signals itself is
the list of trappable `signals'.  I think there's room for a $limits
array, though.

-zefram

Re: Default compctls

[Bart Schaefer]

On Jul 6,  8:10pm, Zoltan Hidvegi wrote:
} Subject: Re: Default compctls
}
} I think compctls belong to the user-level code.  Adding new default
} compctls just increase zsh size and it is quite useless as these are
} usually overriden by the user.

I can't imagine that this is all that significant in terms of size.
Anyway, surely you agree that `builtin' should be corrected from
`compctl -c' to `compctl -B'?

I'd actually be happy to go the other way and REMOVE all the default
compctls except for:

compctl -C -c
compctl -D -f
compctl -T

However, it seems silly to me to have defaults (and incorrect ones at
that) for some builtins, yet not supply the obvious defaults for others.

} Zsh is quite unusable without good startup files anyway.

I wouldn't say that.  I've used it without startup files quite a lot, for
reasons too baroque to bother explaining here.

} > compctl -c -		# BUG!  `-' has special meaning to `compctl'!
} 
} I think -- should mean the end of completion flags as it already means that
} with extended completions.

There are several inconsistencies in zsh as to whether `--' means end
of flags, or whether a solitary `-' means end of flags.  I.e. zsh `echo`
seems to be unique among other shells and /bin/echo in that zsh strips
a solitary leading `-' out of the args to be echoed (no others do).
(Others that I tried don't strip `--' either, though.)

} > Is there any workaround for the bug noted above?
} 
} No, but
} 
} compctl -c exec -
} 
} works.

If I do that and then utter `compctl -L` I get:

compctl -c - -

which does work in the way `compctl -L` implies that it should.  Good.

} Note that Misc/compctl-examples contains better
} compctl's for command, exec, moglob, -.  Look at the section near line 52.

Yes, but I was trying to restrict myself to "simple" compctls because
they should be relatively painless to build in -- a few bytes and one
or two function calls added to compctlsetup(), is all.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Default compctls

[Bart Schaefer]

On Jul 6,  7:38pm, Zefram wrote:
} Subject: Re: Default compctls
}
} There's already a list of signals available.  $signals[2,-3] is the
} list of signals you can actually send to a process.  $signals itself is
} the list of trappable `signals'.  I think there's room for a $limits
} array, though.

Something on another thread led me to think of this:

	limits=("${${(f)$(limit)}%% *}")
	compctl -k limits limit

Or more briefly:

	compctl -k "(${(f)${(f)$(limit)}%% *})" limit

Note the extra (f) in the second form.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"