Re: PATCH: Re: expansion

[Oliver Kiddle <opk@xxxxxxxxxxxxx>]

Sven Wischnowsky wrote:
> 
> Yes, I think I said that the patterns could do with a little improvement.

Yes, and there is still scope for more improvements. Does anyone know
which characters terminate a parameter reference which doesn't use
braces?

> 2) Not using `recexact' as the style name was, of course, intentional,
>    because it really isn't about `recognising', is it? It's about
>    accepting the exact match (it will always take an exact match as
>    one of the possible matches[1]).
>    And accept-exact has the same meaning as recexact, we don't need to
>    reverse it.

Functionally, I can't see that there is a difference between recexact
and accept-exact. Are you basically saying that acceptexact would have
been a better name for the option as well?

> [1] Has anyone else wished he had a style to say `complete anything
>     *but* an exact match'?
>     We already have ignore-line... we could extend that.

It took me a little while to work out what you mean by that but I can
see that it might be useful because someone might feel that they are
only going to press tab if they want to complete something.

It seems to me that the choices are that if the current line is an exact
but ambiguous match, there are three choices: match only the current
exact match, match all matches or match all but the current exact match
so maybe a style with three possible values would be better.

I actually got quite confused while trying to work out what happens in
different situations because of the line in _expand which prevents
substitutions expanding if they expand to an empty string and I was
using an empty variable. Maybe _expand should display a message in this
case.

> I didn't change that even now because I've regretted these
> `mathematically conditional' styles for quite some time now. They
> should be turned into boolean styles and the condition should come
> from somewhere else, e.g. the -e option to zstyle I suggested (see
> 11691).

I meant to reply to that at the time because it seems like a good idea.
It would certainly be a lot cleaner if any sort of evaluations are built
in to zstyle and don't have to be repeated in completion functions.

What exactly do you mean by the word evaluated when you say that 'the
resulting string will be evaluated' in the documentation in the patch:
is the idea that you would use a function. How would this affect the
functions which can be used for tag-order (which, if you remember I use
to avoid completing commands with an empty word). For styles whose
values are arrays, it would be useful to be able to return $value/$reply
as an array.

On the subject of the _expand not doing brace expansion, Sven wrote:

> Change (e)? Use `eval echo ...'? Urgh?

I think it would be a bad idea to change (e) and the eval is going to be
slow. I think I said it before a while ago but it would be nice if there
was clearly defined ways to do the various types of expansion,
individually or together. A (b) to do brace expansion might solve the
brace problem but we would maybe have fewer problems in _expand if there
was syntax like (e:pab:) to do parameter, arithmetic and brace expansion
with other letters for things like ~, =, history, command and whatever
other expansions we have.

This would have some problems though: expansions which expand to things
which can be further expanded for example but I'd have thought these
have all be addressed in the code before. The other trouble with
expansion as a part of completion is that completion by definition deals
with things which are incomplete so we have the problem of what to do
with things which aren't syntactically correct yet. For example, try:
a(<tab> and you will get '_expand:78: bad pattern: a(' because of the
lack of a closing bracket.

Oliver