Re: Inserting all completions

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

(I've dropped zsh-users from the discussion, it's getting pretty thick.)

On Jul 20,  9:53am, Sven Wischnowsky wrote:
} Subject: Re: Inserting all completions
}
} > > The question then is, how to write function_to_compute_reply() in a
} > > suitably generic manner ...
} > 
} > Hmm.  The existing Completions/*/* functions would be ideal for this, if
} > there were some way to refer to "all the matches that have already been
} > added by some other completer."
} 
} 1) a way to get at the strings for the matches added
} 2) some more magic with compstate[insert]
} 
} Unfortunately 1) is not trivial:
} 
} - we really have the information about the matches only *after* the
}   completion widget finished, because then the code that sorts the
}   matches and eliminates duplicates is run

That may not be as much of a problem as you think.  The interface for
getting at the previous matches can be exactly like "compadd -A array"
except that the source is the existing list of potential matches rather
than the command line arguments; the only side-effect would be that the
matches copied into the array would be removed at that time from the
internal list.

Perhaps an option "G" (for "get") that's combined with -O or -A:

    compadd -GA [-J group] array
    compadd -GO [-J group] array
	Copies the internal list of completions not yet added to the
	command line into the named array and erases the internal list
	(as if no completions had ever been added).  The completions
	must be re-added later, for example with "compadd $array", in
	order to be considered as matches.  If -J group is given, only
	the matches from the named group are retrieved.

If "compadd -[AO]" isn't performing the sorting/matching, document that,
thus effectively punting it to the later "compadd".

The problem I see is that this would dissipate the cloud of other data
that surrounds each match, such as whether it should be added with -U
or -Q, the -X strings, etc.  But maybe that's OK, as there can't be very
many reasons that a function wants to intercept all the matches added
"ahead of" it.

} - the completion-inside-braces-problem: if we have a{b<TAB>, the
}   matches are abx, aby, and so on and only the match-insertion code
}   really knows where to re-insert the brace(s) correctly

I'm not sure how that one interacts with the above suggestion.

} The 2) is something I only thought about now. That wouldn't be too
} hard, I think. We could make compstate[insert] accept a comma-
} separated list of ranges or something like that (a la cut), e.g.:
} `compstate[insert]=1-' would insert all matches, and something like
} `compstate[insert]=1,3,5-10' would insert the first, third, and
} fifth-to-tenth match (in that order).

That's a nice idea, but one still needs a way to find out what the
first, third, and fifth etc. matches *are* in order to decide whether
to insert them.  Otherwise it might as well be an all-or-nothing thing.

Maybe all-or-nothing is actually sufficient; what about simply:

	compstate[insert]=expand

Which would act much like the _expand completer with only expand_glob.

Thinking about this, however, makes me notice that it's always dangerous
to "chain" completers together when any of them use compstate[], because
there's no way to tell (a) whether the input state is from the completion
system or is the output state of some previous completer, nor (b) whether
changing the state is going to garble the results from some previous
completer.  In that sense, actually destroying the previous completer's
data with my suggested "compadd -G" might be preferable ...

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