Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> 
> ...
> 
> I think implementing some new builtins is the way to go, but I don't
> think the right thing is to have them read a completely new syntax from
> some external file.  I actually have some experience with this:  When
> Z-Code implemented attachment processing extensions, similar to mailcap
> for MIME, in the Z-Mail product, we added a completely new config file
> with new syntax.  Prior to that, all configuration had been in "zscript,"
> the csh-like language accepted by zmail's command parser, and it became
> a hassle (for sysadmins especially) to have to keep track of the extra
> files and learn the extra syntax.  We soon had to add a zscript builtin
> with command-line arguments to replicate the new config's semantics, so
> customizations could all live in the same place.
> 
> In short, if you've already got a programming language, stick with it.
> 

I agree that we should use as much of the current shell syntax/lexer/parser/...
as possible, I just wouldn't want to change too much of that
code. I hadn't thought of using more than one new builtin, maybe there 
is a way we could go...

> } Also, we should have some kind of democratic decision about the
> } syntax. Let me start with a first suggestion:
> 
> I think what you've outlined is actually more verbose than necessary.
> For example:
> 

Yes, I know, it was done to improve readibility, which, if I
understood the complaints correctly, is one of the major problems with 
compctl.

> } pattern */X11/* do     # `pattern' is for defining pattern compctls
> } command xterm do       # `command' is for normal compctls
> 
> Why separate them?  Will it ever make sense to say
> 
> 	command *X* do
> 
> ??  Why not treat everything with wildcards as a pattern, and otherwise
> as a command?
> 

That's what I did with compctl...

> Another example:
> 
> }       strings display name  # this is -k '(display name)'
> 
> Since we're not talking compctl command lines any more, we don't need
> both "inline array syntax" and named arrays, so just use a standard
> array assignment and then refer to it by array name later.
> 

If we have a syntax for setting arrays in the context where the
completion control is defined (i.e. if we find a nice way to use the
things you hint at above and below): yes!

> I'd rather see something like "case" syntax:
> 
>    case $command[1] in	# command is set as if by `read -Ac command`
>       (*/X11/*)
>         if [[ $command[$current] == -* ]]	# `read -nc current`
> 	  reply=(display name)
> 	fi
> 	;&
>       (xterm)
>         if [[ $command[$current] == -* ]]
> 	  reply=($reply 132 title)
> 	fi
>         ;;
>     esac
> 

This is the reincarnation of your `hey we can do all compctls in one
compctl -T' (what you mentioned below), right?
For me (the way I use compctl), this is ok, but there may be problems:
  - you can't separate the thing above into different parts/files as
    easily as different commands
  - it doesn't make things simpler to read/understand (esp. if this
    becomes large)
  - a minor complaint: the `case $command[1] in ...(*/X11/*)' looks
    like matching the first word in the command, which is not what
    pattern compctls currently do: they first try to match the first
    word, if that doesn't match, the path name of the command is
    looked up and matching is done on that

> }   paths                # this is `-/'
> }   files *.dvi          # `files' with strings is `-g ...'
> 
> This kind of thing is a good idea.  So is PWS's suggestion of having
> longer names for the c[] and w[] and so forth extended patterns.  But
> both of those could be accomplished by introducing one new builtin
> that is otherwise equivalent to compctl.
> 
> On Aug 20, 11:48am, Bruce Stephens wrote:
> } Subject: Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand)
> }
> } On the other hand, if you isolate the completion stuff into separate
> } files, then that probably makes things a lot saner (there're surely
> } going to be ambiguities otherwise), and it leaves open the possibility
> } of "byte compiling" the completion files for speed.
> 
> I think you could accomplish both of these goals by, for example, adding
> a new special function name (ala chpwd, precmd, and preexec) and getting
> the flow-control parts of completion by parsing that function.
> 
> (You can get this effect today, almost, by using
> 
> 	compctl -Tx 'W[0,*]' -K completer
> 
> but then you must reimplement all of compctl in the completer function.
> Essentially, I think this is the direction we should go, but provide a
> lot of builtin help towards "reimplement all of compctl in completer".)
> 
> If names like "command" and "current" in my example above had predefined
> meaning within this special function, $command[$current] == -* could be
> recognized and optimized to the equivalent of -x 's[-]'.  Conceivably.
> 

This is interesting but certainly doesn't simplify things (which was
almost all I was thinking about). It also makes me think again about
the hooks I would like to see in different places.

> On Aug 20,  1:17pm, Sven Wischnowsky wrote:
> } Subject: Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand)
> }
> } Yes, I was aware of that problem. If the completion control command
> } would read stdin we could put it into the normal setup files with the
> } definitions in here-documents (which is a bit ugly).
> 
> That's an approach I'd also thought of, and it'd almost be OK, but I
> think we can do better.
> 

Agreed again.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx