Re: PATCH: _expand, _expand_word, and their doc

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Oct 6, 10:14am, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
} > } > What would you (or anyone else) think of removing
} > } > insert-all-completions from _expand entirely (thus eliminating
} > } > the -c option) and instead put compstate[insert]=all at the end
} > } > of _expand_word (after _main_complete)?
} 
} Anyway. The reason why I don't really like the completions style to be 
} handled there is that -- as Andrej mentioned once -- the matches are
} generated different than the expansions. Not even by _expand itself
} (which just looked like a clever trick at that time).

Hm.  I don't have any overwhelming disagreement with that; the issue is
not so much that _expand_word should handle it, as that _expand should
not -- Andrej is clearly correct that _match is what actually does the
most-correct thing in terms of generating the possible completions, so
the question is how to get them all (offered to be) inserted at once.

} So, I would mainly vote for changing the way the completions are
} generated, using the way we do it in _prefix and _ignore, only the
} other way round. I.e. we look up the completer style in the new
} context and use the global list if it isn't set there. From that list
} we remove the `uninteresting' completers as Bart did in _e_w (_prefix
} and _ignore should probably do the same). That way the whole thing
} would be self-contained again.

I really am not entirely happy with the trick I used in _e_w.  What it
really should do is simply allow the completions to be generated the
usual way and then stuff them all as a single match into a new group
that could be named in the tag-order style (e.g. the expansion wouldn't
appear if that style wasn't named in tag-order).

} Then we leave it either in _expand or put it into a separate
} completer, depending on how strongly people feel that this is
} different from what _expand does [...].

I'd say we should use a new completer which has to appear very late in
the completer list, and which modifies the handling of the completions
that are generated before it is called.  As you suggest here:

} [...] And I think it would be possible, probably by adding 
} a new option to compadd which makes it add a string with all matches
} generated so far (and then remove the `all' special value for
} compstate[insert]).

The only issue with removing the "all" special value is that we still
should be able to express the idea that all the completions should be
immediately inserted.  If I understand your suggested change to compadd
correctly, we'd just end up with all the completions as an *additional*
choice.

} With that, it would almost make sense to add that feature to _complete
} itself, making it look (feature-wise) more like _expand.

I don't think adding it to _complete is good enough, in particular because
one may want to add all the completions generated by _match, which is not
usually called until after _complete.

On Oct 6,  4:34pm, Andrej Borsenkow wrote:
}
} > > You're starting from an initial pattern and expanding it into
} > > a set of strings, aren't you? What difference does it make
} > > whether the way you got those strings was by globbing, parameter
} > > substitution, history, or by invoking the completion system, or
} > > anything else?
} 
} Pragmatical answer: because currently we can select between individual
} expansions or all expansions, but cannot do it with completions.

That's a non-answer: _expand_word does NOT select between individual
expansions or all expansions.  It just inserts all of them.  So I ask
again, why does it matter where "all of them" came from?

The difficulty of course is that only "completion widgets" can be used to
generate completions, so you have to go through the completion system even
if what you want in the end is expansion.

} Metaphysical answer: I always considered expansion to be complementary
} to completion. Completion is always context-sensitive (in the very
} broad sense sometimes). We select from the fixed set of possible
} values; this set depends on context but values itself do not depend on
} initial pattern. With expansion we just evaluate the pattern; thus,
} the set of values does not depend on context in any way, but values
} itself obviously depend on initial string.

I don't agree with this.  Globbing, for example, is a context in which
the fixed set of possible values are files on the file system.  The glob
pattern doesn't create the values, it just selects the interesting ones.
So you've just argued that "filename generation" should not be considered
expansion, either -- but generating filenames is something that "expand",
in the expand-or-complete sense, has always done.

} Exactly the fact that completion is context-dependent action makes it
} possible (in most cases) to group matches, to provide decriptions etc.
} All this is inherently impossible with expansions, that do not have
} any internal structure (the only sensible way to group them is by the
} way intial string is evaluated - globbing, parameter expansion - that
} is done currently).

This might be an argument for why the _expand completer should not exist
but I don't find it relevant to the question of why _expand_word should
not be used to generate completions.

On Oct 6,  3:00pm, Sven Wischnowsky wrote:
} 
} I already decided to play a bit to see how difficult to implement this 
} is (both in C and shell code).

Then once again I'm probably a bit late with this reply, but ...

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net