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

[TGAPE! <tgape@xxxxxxxxxxxxx>]

This thread was started by someone who wanted to add some functionality
to zsh.  What he was asking for sounded somewhat reasonable.  I went to
another window, and I tried a test.

	setopt dirs^[b^I
markdirs nohashdirs pathdirs

It worked, no problem.  I'm running 3.1.1.  What is the most depressing
about this is that it is very common.

The list then hashed about how to solve this problem, how to implement
it, how to make it simpler to use after implementation, and so forth.
My heart was gladdened when I finally bespied the word simplify, because
that is what zsh needs at this point; I've not upgraded since 3.1.1,
because it does everything I need, and I've not heard of improvements in
performance (i.e. speed) since.  I was horrified to see what their idea
of simplification was.  Zsh is getting seriously bloaty.

The only bright spot in this was, at long last,

Bart Schaefer wrote:
>
> Let's think about this a different way for a moment.
>
> First, consider the manipulations that completion performs on the input
> line:

<snip>

Someone finally seems to be actually studying the problem, rather than
doing a quick patch like this group is so wont on doing.  (Don't get me
wrong, it frequently is very useful, but this isn't a quick-fix problem,
this is something huge and complicated.)  Basically, the current problem
is probably best described as, "Well, we've added in virtually all the
completion functionality we can think of, but it's now a hairy mess.  We
need to bring it together under one metaphore, one unified structure."

Another tact, which has been being worked, is to make better
documentation for it.  This is also a good idea, but I haven't seen
anyone proposing any improvements on how to describe things on here.  I
think that is probably at least as important as the structure with which
you define the completions.

> It's sort of a RISC v. CISC argument, actually; it's easier to understand
> what's going on with RISC instructions, because each one is simpler, but
> you have to issue a lot more of them to get anything done.  The current
> compctl is confusing for two reasons:  (1) it uses single-character and
> thereby minimally mnemonic options to describe everything; and (2) the
> effect of any one of those options may be a very complex change to the
> input, and so combining them is either bewildering or impossible.
> 
> Addressing (1) with a flowery syntax doesn't help with (2), and I think
> that if (2) were cleaned up then the syntax for (1) wouldn't need to be
> as flowery.

The problems I've basically had with this have been one of flow, caused
by (2).  A helper program would do wonders to solving this.  This could
also aleiviate (1), since the person would no longer need to depend on
the key letters while they're programming.

I'm envisioning something which displays a menu, with the key letters in
brackets.  When an option is chosen, it changes to have a brief
description of the option, and guides for how to fill in any arguments
to the command.

As I'm thinking about it, I could even develop it utilizing completion
code, however, I think that this would send the wrong message; at some
point in time, functionality gets to be silly.  For example, ** may be
useful for simple cases, but when I do something that would take 240 or
more characters with find, it gets excessive.  Sure, I'm still under 80
characters with zsh globbing, but the point is that it is merely
confusing and inefficient; find runs much quicker, and I'll spend more
keystrokes moving through the zsh documentation, and flipping between
virtual consoles, than I'll save over the find line.  Not only that, but
find is easier to read later.  (Plus, find is not many keystrokes;
compctl has seen to that.)

Ed Grimm