Re: all-matches with a suffix

[martin.ebourne@xxxxxxxxxxxx]

> The problem here is that it has to cheat if you want to call it that.
> There is this pseudo match I've been talking about already, containing
> all the other matches.  In order to insert that match, it inserts the
> other matches one by one, as if one were in a menu completion and
> repeatedly using accept-and-menu-complete, typing spaces between the
> matches.

I'm not surprised - it certainly looks like that's what its doing since the
line visibly 'grows' as it is entered.

Is it not possible to build up the full match and add it in one go?

> Now the `-r' option means that the suffix (-S ', ') should
> be removed if the next character typed is a space (or a comma, or...).
> That auto-remove thing is certainly the right thing when used
> interactively, but for this all-matches thing...
>
> Hm, we had some discussion about all this suffix handling anyway, so
> maybe we should start collection other problems people see or have
> seen with it and then find the real solution.  At least I can't see
> any simple solution now, without adding another option to compadd,
> telling it how it should behave for a-a-m-c.  and that would look like
> a hack, somehow.

Well the option may not be such a bad idea. I can think of occasions where
you would want a space separating the results, and others where you
wouldn't. It's not obvious how the completion code could otherwise decide.
Four cases I've though of so far are:

1. Expanding all matches on a list of directories, you would probably want
the trailing '/' removed, and the results separated by spaces. This is what
it does currently.

2. Expanding the SQL selection list you would want the separator ', ' used
as is (though an extra space wouldn't hurt). Currently the line ends up
being corrupted.

3. Expanding 'dd conv=*' you would want the separator ',' used as is, and
an extra space would be a problem. (eg. 'dd conv=ascii,lcase,') Currently
it expands to a list of 'conv=value ', which I guess is ok, but it's
probably not what I'd expect. Also it may depend on the command if that is
valid.

4. Expanding 'dd *' you would want the separator '=' used with a space
appended. This is what it does currently.

In addition, for case (2), if I had

     select table.* from table

and expanded after '*', I'd want

     select table.col1, table.col2, table.col3, from table

which is a lot like (3) currently behaves (though currently the line still
gets corrupted due to the ', ' suffix removal.)


Finally, a separate note about 3, is that if I enter:

     dd conv=a

and complete, I get

     dd conf=ascii,

which would be fine. But then instead of offering more completions for the
list when I try completion again, it tries to correct the word to 'ascii'
(1 error). It doesn't succeed though.

Cheers,

Martin.