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

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 19, 11:54am, Sven Wischnowsky wrote:
} Subject: Re:  EZ-compctl (was Re: ideas: free-search-complete, noexpand)
}
} Anyway, I would like to go in a direction where we have a simpler (and 
} more readable) form to define completions and than add some syntactic
} sugar for the most common cases. Bart suggested a syntax that is
} modeled after the normal shell syntax (if I remember and understood
} him correctly). I like that idea.
} 
} Since I wouldn't like to mess with the shell lexer/parser just to add
} a new syntax for completion control, I would (as a first step)
} implement it as a new builtin that gets some filenames arguments (or
} read stdin), reads these files and expects the new syntax there.

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.

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

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

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.

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

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

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.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com